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Annual  Review  Introduction 

This  year’s  annual  Review  provides  another 
sample  of  research  in  computer  science  at  Car- 
negie-Mellon.  Like  our  previous  samples  it  is 
both  revealing  and  concealing.  In  terms  of  con¬ 
tent  this  issue’s  emphasis  on  system  building 
systems  (the  paper  by  Bill  Wulf  and  also  by 
Newell  et  at.)  is  certainly  revealing  of  a  real 
emphasis  in  the  CMU  environment — an  emphasis 
that  David  Fisher’s  paper  on  control  structures 
broadens  a  bit,  but  fundamentally  reinforces. 
Donald  Loveland’s  paper  suggests  that  our  re¬ 
search  is  broader  than  this,  not  only  by  repre¬ 
senting  a  more  mathematical  concern,  but  also 
by  indicating  a  connection  with  artificial  intelli¬ 
gence.  But  this  entire  sample,  taken  all  together, 
still  conceals  the  major  growth  in  activity  that  has 
occurred  this  last  year  in  the  design  of  computer 
hardware  systems  and  in  the  development  of 
speech  recognition  systems. 

There  are  more  basic  ways  in  which  this  annual 
Review  is  both  revealing  end  concealing.  When 
placed  as  the  latest  member  of  a  sequence  of 
such  Reviews,  it  reveals  a  continued  and  invariant 
commitment  to  the  development  of  a  computer 
science.  It  reveals,  thus,  an  unchanging  aspect 
of  this  environment.  But  it  thereby  conceals  that 
we  have  just  undergone  our  most  major  organiza¬ 
tional  change  since  we  became  a  Department  of 
Computer  Science  in  1965.  Alan  Perlis  has  left  to 
become  the  Higgins  Professor  of  Computer  Sci¬ 
ence  at  Yale  University.  Much  of  the  outside 
world  has  identified  computer  science  at  CMU 
with  Alan  Perlis.  Still,  only  those  who  have  been 
in  this  environment  can  appreciate  how  thorough¬ 
ly  it  was  saturated  with  his  presence.  We  wish 
him  well  at  Yaie.  He  claims  to  be  finished  with 
department-heading  and  such  like  occupations. 
We  also  wish  him  well  in  this  resolve. 

Joseph  Traub  has  joined  us  as  the  new  head 
of  the  Department  of  Computer  Science,  having 
previously  been  at  the  University  of  Washington 
in  Seattle  and  before  that  at  Bell  Laboratories. 
His  principle  research  interest  is  in  numerical 
mathematics,  an  area  in  which  we  have  not  pre¬ 
viously  laid  much  emphasis.  We  welcome  him 
and  look  forward  to  a  continued  strengthening 
A.N.  and  broadening  of  the  research  that  has  been 
18  Aug  71  illustrated  by  these  annual  Reviews. 
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A  Brie?  Primer  on  Resolution 
Proof  Procedures 

Donald  W.  Loveland 

For  mechanical  theorem  proving  the  decade  of 
the  sixties  has  been  dominated  by  the  develop¬ 
ment  of  complete  proof  procedures  of  first  order 
logic.  Moreover,  this  approach  has  itself  been 
dominated  by  the  off-shoots  of  one  complete 
procedure,  resolution.  A  complete  proof  proced¬ 
ure  in  first  order  logic  Is  a  mechanical  procedure 
which  can  always  verify,  given  sufficient  time 
and  resources,  that  a  given  first  order  theorem 
is  a  theorem.  Complete  procedures  cannot  iden¬ 
tify  all  non-theorems  as  such.  This  article  con¬ 
tains  a  summary  of  the  resolution-based  complete 
procedures  (here  called  resolution  strategies). 
Special  strategies  for  handling  the  equality  rela¬ 
tion,  though  important,  have  been  excluded  here. 

The  primary  purpose  of  an  article  written  for 
the  Computer  Science  Research  Review  of  CMU 
is  to  portray  active  areas  of  faculty  research. 
Resolution-type  proof  procedures  are  of  in¬ 
terest  to  the  author!7'6!  and  to  Professor  Peter 
Andrews'1-2!  of  the  CMU  Mathematics  Department. 
The  author  believes  that  the  best  way  to  present 
the  results  of  this  interest  is  to  present  a  general 
picture  into  which  the  results  fit. 

A  second  purpose  of  this  article  is  to  fill  a 
present  gap  in  the  survey  literature.  Until  now 
there  has  been  no  article  which  a  computer  scien¬ 
tist  (including  a  student)  with  a  one  semester 
logic  background  can  read  for  a  brief  technical 
survey  of  basic  resolution  theory,  although  the 
word  "resolution''  is  in  almost  every  computer 
science  student’s  vocabulary.  This  article  is 
structured  to  provide  enough  information  (with¬ 
out  proof)  to  allow  a  person  to  design  a  reason¬ 
able  resolution  theorem-prover  with  an  awareness 
of  the  several  alternate  approaches  available 
to  him. 


The  article  is  split  into  sections  with  the  intent 
that  some  will  be  read  more  closely  than  others 
depending  on  the  reader’s  background  and  inter¬ 
est.  In  particular,  section  1  concerning  the  pre¬ 
paration  of  a  formula  for  input  to  a  resolution 
procedure  can  be  omitted  by  anyone  with  some 
exposure  to  the  literature  of  this  area.  The  work 
at  CMU  (related  to  first  order  resolution  theory) 
is  contained  within  section  5.  The  only  references 
to  the  people  responsible  for  the  ideas  reported 
here  are  in  section  7. 

Almost  all  of  the  papers  so  far  published  con¬ 
taining  results  cited  in  this  paper  are  referenced 
in  Meltzer's  paper.10  To  a  lesser  extent  the 
references  appear  also  in  the  Anderson  and 
Bledsoe  paper.8  Also  listed  are  J.  A.  Robinson’s 
basic  paper  on  resolution,12  two  papers  of  inter¬ 
est  not  referenced  in  Meltzer’s  paper,79  a  basic 
logic  text"  where  the  logical  concepts  needed 
for  this  paper  can  be  found,  and  the  relevant 
papers  written  at  CMU.1''  For  further  study,  the 
Robinson  paper  followed  by  the  Anderson  and 
Bledsoe  paper  is  appropriate  for  those  interested 
in  the  completeness  aspects  of  these  proof  pro¬ 
cedures,  while  the  Meltzer  paper  is  more  appro¬ 
priate  for  those  less  inclined  in  this  direction. 
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1.  Preparing  a  Formal  Expression 

The  sentence  to  be  tested  for  theoremhood  is 
written  in  the  (first  order)  predicate  calculus. 
Preparation  consists  of  two  parts:  formation  of  a 
first  order  sentence,  or  closed  formula,  which 
expresses  the  intuitively  conceived  theorem  and 
then  conversion  of  the  sentence  to  proper  input 
form.  Often  the  first  part  is  partially  completed 
by  drawing  on  standard  knowledge  of  the  field 
in  question.  This  part  can  be  quite  difficult  to 
execute  successfully  for  many  reasons,  The  sec¬ 
ond  part  is  a  straightforward  algorithmic  pro¬ 
cedure.  A  brief  discussion  will  be  given  of  the 
nature  of  the  formation  of  a  first  order  sentence, 
chiefly  by  example,  followed  by  a  procedure  for 
preparation  of  a  sentence  for  input  to  a  resolu¬ 
tion  proof  procedure. 

A  proposed  theorem  is  often  presented  as  a 
set  of  hypotheses  about  an  environment  (call 
such  statements  axioms)  implying  some  desired 
assertion.  The  chief  difficulty  in  formulating  such 
a  sentence  (we  assume  hereafter  all  sentences, 
or  formulas,  are  assumed  to  be  in  first  order 
logic)  is  to  describe  sufficiently  the  predicates 
introduced  by  axioms  so  as  to  disallow  unin¬ 
tended  interpretations.  This  cannot  be  done  in 
general,  as  any  student  of  logic  knows,  but  in 
sufficiently  simple  cases  it  can  be  accomplished. 
It  is  usually  the  case,  anyway,  that  a  finite  set  of 
axioms  exist  which  sufficiently  describes  the  en¬ 
vironment  with  respect  to  the  “crucial  properties" 
to  allow  a  proof  of  any  given  "true"  formula.  How¬ 
ever,  these  crucial  properties  are  not  usually 
known  in  advance  of  the  proof,  so  one  usually 
models  c.ie’s  intuition  and  tests  the  results. 

Consider  first  a  quite  simple-minded  real  world 
example,  the  question  if,  in  a  particular  environ¬ 
ment,  a  monkey  can  get  some  bananas  suspend¬ 
ed  from  a  ceiling  of  a  room.  Although  the  result¬ 
ing  theorem  is  trivial  for  most  theorem  provers, 
the  process  of  formation  of  the  statement  may  be 
instructive.  Figure  1  lists  the  chosen  constants 
and  predicates  (with  their  intended  interpreta¬ 
tion)  plus  the  axioms  in  the  final  input  form.  The 
input  form  is  developed  later  in  this  section.  How 
might  a  set  of  formulas  which  generate  the 
axioms  of  Figure  1  be  chosen? 


Figure  1. 

Monkey-banana  problem. 


Constants: 

M  =  monkey 
B  -  bananas 
C  =  chair 
F  -  floor 
Predicates: 
reach(x.y)  = 
get(x,y)  = 
andex(x)  = 
close(x.y)  = 
on(x,y)  = 
under(x,y)  = 
tall(x)  = 
inroom(x)  = 
move(x,y,z)  = 
climb(x,y)  = 
Axioms: 


x  can  reach  y 
x  can  get  y 

x  is  a  dexterous  animal 
x  is  close  to  y 
x  is  on  y  (x  can  get  on  y) 
x  is  under  y 
x  is  tall  (x  is  high) 
x  is  in  the  (given)  room 
x  can  move  y  near  z 
x  can  climb  y 


(i)  ~  reach(x.y)  get(x.y) 

(ii)  -  andex(x)  ~  close(x.y)  reach(x,y) 

(iii)  ~  on(x,y)  ~  under(y.B)  ~  tall(y) 

close(x,B) 

(iv)  ~  inroom(x)  ~  inroom(y)  ~  inroom(z) 

—  move(x,y,z)  c!ose(z,F)  under(y,z) 

(v)  -  climb(x,y)  on(x,y) 

(vi)  andex(M) 

(vii)  tall(C) 

(viii)  inroom(M) 

(ix)  inroom(B) 

(x)  inroom(C) 

(xi)  move(M,C,B) 

(xii)  —  close(B.F) 

(xiii)  climb(M,C) 

Assertion:  get  (M,B) 
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The  assertion  to  be  tested  is  whether  or  not 
the  monkey  gets  the  bananas.  Suppose  the  set¬ 
ting  is  a  room  with  the  bananas  suspended  in  a 
corner  away  from  both  the  monkey  and  a  light 
chair.  The  monkey  cn  the  chair  would  be  tall 
enough  to  get  to  the  bananas.  The  goal  is 
"get(M,3)”  which  is  named  as  the  assertion. 
Suppose  the  word  "reach"  means  physical  prox¬ 
imity  plus  outstretched  arm  in  the  proper  direc¬ 
tion.  Then  a  natural  choice  of  axiom  is: 

(1)  reach(x.y)  d  get(x,y) 

That  is,  for  all  x,y,  if  x  reaches  for  y,  x  gets  y. 
Note  the  implicit  universal  quantification  of  x  and 
y;  this  is  traditional  and  adopted  here.  The  predi¬ 
cate  reach  has  additional  strong  connotations 
which  must  be  sufficiently  described  by  one  or 
more  further  axioms: 

(2)  [andex(x)  &  close(x.y)]  d  reach(x,y) 

This  constrains  the  predicate  "reach"  but  only  by 
introducing  two  unconstrained  (or  undefined) 
predicates.  It  is  reasonable  simply  to  assert 
"andex(M)"  (see  axiom  vi).  More  axioms  could 
be  provided  concerning  the  predicate  "andex" 
to  better  specify  the  situation  in  hopes  that  this 
would  help  establish  thn  assertion.  We  refrain 
from  doing  so  here  to  keep  the  example  or  mod¬ 
est  size.  By  hindsight  it  is  known  that  such  extra 
axioms  actually  are  not  needed  in  this  case.  The 
predicate  "close"  is  constrained  by  the  descrip¬ 
tion  (definition): 

(3)  [on(x,y)  &  under(y.B)  &  tall(y)  ]  D  close(x.B). 
Continuing  in  this  manner,  "under”  and  "on"  are 
themselves  constrained: 

(4)  [inroom(x)  &  inroom(y)  &  inroom(z)  & 

~  close(z.F)]  d  [move(x,y,z)  D  under(y,z)l  ; 

(5)  climb(x.y)  D  on  (x,y). 

These  constraints  establish  the  need  for  addition¬ 
al  predicates,  but  at  this  stage  it  is  not  unreason¬ 
able  to  define  them  by  specific  identification  of 
object  with  property  as  was  done  with  "andex". 
Hence,  add  axioms  (vi)  through  (xiii)  of  Figure  1. 

As  stated  before,  the  assertion  about  the  environ¬ 
ment  is 

(6)  get(M,B). 


The  candidate  theorem  is  the  universal  closure 
of  the  conjunction  of  formulas  (1)  through  (6)  and 
axioms  (vi)  through  (xiii).  By  conjunction  is 
meant  connecting  the  formulas  by  &’s  and  by 
universal  closure  is  meant  adding  sufficient  uni¬ 
versal  quantifiers  around  the  outside  of  the  total 
formula  to  le&ve  no  free  variables. 

As  an  example  of  a  mathematical  system  that 
is  described  by  a  finite  number  of  axioms,  a  nat¬ 
ural  candidate  is  group  theory.  Let  P(x,y,z)  be 
interpreted  as  x  •  y  =  z.  Then  a  group  is  a  struc¬ 
ture  which  satisfies  the  following  axioms  (recall 
axioms  are  equivalent  to  their  universal  closure)* 

(7)  3zP(x,y,z)  closure 

(8)  [P(x,y,u)  &  P(y,z,v)j  d  [P(x,v,w)  =  P(u,z,w)] 

associativity 

(9)  3x[Vy  P(x,y,y)  &  Vy3zP(z,y,x)j 

Left  identity  and 

Left  inverse 

The  statement  (7C)  &  (8C)  &  (9‘)  D  3x[VyP(x,y,y)  & 
Vy3zP(y,z,x)],  where,  e.g.,  (7C)  denotes  the  univer¬ 
sal  closeure  of  axiom  (7),  illustrates  a  reasonable 
formula  to  test  for  theoremhood.  The  intended 
interpretation  is  that  right  inverses  exist  for  each 
element  of  a  group.  The  input  form  of  a  theorem 
slightly  stronger  than  this  one  will  be  given  later. 

Elementary  number  theory  may  be  the  most 
important  of  all  axiomatic  mathematical  theories, 
but  its  natural  axiomization  involves  an  infinite 
number  of  first  order  axioms.  A  large  portion  of 
elementary  number  theory  can  be  handled  with¬ 
in  a  finite,  and  indeed  relatively  small,  number  of 
axioms,  but  in  such  formulations  even  the  sim¬ 
plest  results  of  number  theory  seem  beyond  the 
present  procedures  when  reasonable  time  limits 
are  imposed.  This  is  one  of  the  reasons  why  a 
different  approach  to  theorem-proving  may  domi¬ 
nate  the  next  decade.  However,  this  will  not 
automatically  be  the  case.  Heuristics  superim¬ 
posed  on  resolution  strategies  may  outperform 
even  supposedly  preferable  systems,  just  as  the 
refinements  to  the  internal  combustion  engine  has 
to  daie  allowed  it  to  dominate  the  steam  engine 
in  practice. 
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Of  course,  formulas  simply  to  be  tested  for 
logical  valia  ty  (or  unsatisfiability)  are  suitable 
inputs  also.  For  example,  one  might  wish  to 
establish  that  the  following  formula  is  valid: 

(10)  Vx[A(x)  D  B(x)]  D  [3xA(x)  D  3xB(x)]. 

Here  quantifiers  take  the  smallest  scope  con¬ 
sistent  with  the  parenthesizing.  This  is  also  true 
for  negation  symbols  when  used, 

The  proof  procedures  under  discussion  are 
capable  of  indicating  that  certain  formulas  are 
unsatisfiable.  Therefore,  the  formulas  actually 
used  for  input  to  the  resolution  procedures  are 
chosen  so  that  unsatisfiability  is  the  quality  to 
be  ascertained.  Thus,  a  formuia  to  be  tested  for 
validity  is  negated  to  yield  a  formula  to  be  tested 
for  unsatisfiability,  the  second  formula  being  un¬ 
satisfiable  if  and  only  if  the  original  formula  is 
valid. 

Steps  0  through  7  below  describe  how  to  con¬ 
vert  a  closed  formula  to  an  appropriate  input 
form.  The  input  formula  is  said  to  be  in  Skolem 
functional  form  when  it  is  in  the  format  obtained 
at  the  end  of  step  7. 

Assume  the  formula  presented  for  testing  is 
closed.  If  the  formula  has  free  variables,  and  the 
test  is  for  validity,  add  to  the  left  of  the  formula 
a  universal  quantifier  of  each  free  variable.  The 
order  of  attachment  is  unimportant.  For  ex¬ 
ample,  the  formula  A(x)  D  A(y)  should  be  re¬ 
placed  by  VxVy(A(x)  D  A(y)).  If  the  test  is  for  un- 
satisfiability,  add  existential  quantifiers  in  like 
manner. 

Step  0.  Obtain  unsatisfiable  formula.  If  the  given 
formula  is  to  be  tested  for  validity,  negate  the 
formula.  If  the  test  is  for  unsatisfiability,  do  not 
negate. 

Example:  Test  equation  MO)  for  validity.  Thus 
negate  (10)  giving: 

(11)  ~  IVxIA(x)  ^  B(x) ]  d  [3xA(x)  D  3xB(x)J] 

Step  1.  Eliminate  and  D.  Change  each  occur¬ 
rence  of  R  S  to  (~  R  V  S)  &  (~  S  V  R). 
Change  each  occurrence  ofRDSto~RVS 
Applying  this  step  to  (11)  gives: 

(12)  ~[~Vx[~  A(x)  V  B(x) ]  V  [~  3xA(x)  V 

3xB(x)]J. 


Step  2.  Rename  variables.  Change  names  of 
bound  variable  occurrences  when  necessary  so 
that  each  variable  appears  in  one  quantifier.  Any 
change  of  name,  of  course,  must  be  uniform 
throughout  the  scope  of  a  quantifier.  The  re¬ 
naming  of  variables  is  necessary  to  make  the 
transformations  of  step  3  acceptable 
Example  (cont’d):  From  (12): 

(13)  -  [~  Vx[~A(x)  V  B(x)]  V  [~3yA(y)  V 

3zB(z)]]. 

Step  3.  Place  in  prenex  normal  form.  Replace 
the  formula  obtained  after  step  2  by  another 
having  the  quantifiers  all  moved  to  the  left  as  far 
as  possible  using  only  the  following  transforma¬ 
tions  (here  A  and  B  are  arbitrary  formulas  and 
x  denotes  an  arbitrary  variable): 

(a)  ~  VxA  to  3x  ~  A 
~  3xA  to  Vx  ~  A  ; 

(b)  VxAVB  to  Vx(AVB)  ,  AVVxB  to  Vx(AVB)  , 
3xAVB  to  3x(AVB)  ,  AV3xB  to  3x(AVB)  ; 

(c)  As  (b),  with  &  everywhere  replacing  V. 
Notice  that  Vx(3yAVB)  can  go  to  Vx3y(AVB)  but 
not  to  3yVx(AVB).  Thus  quantifier  order  is  im 
portant.  However,  3yA  V  VzB  can  go  to  either 
3yVz(A  V  B)  or  Vz3y(A  V  B).  Within  the  range  of 
permissible  moves,  it  is  very  desirable  to  bring 
each  existential  quantifier  to  the  left  of  as  many 
universal  quantifiers  as  possible.  The  reason 
will  become  evident  later. 

Example  (cont’d.):  From  (13): 

(14)  3yVzVx  A(x)  V  B(x)]  V  [~  A(y)  V 

B(z)  ]  ] 
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Step  4.  Eliminate  3.  Replace  all  existentially 
quantified  variable  occurrences  by  Skolem  func¬ 
tions.  For  each  existentially  quantified  varaible 
introduce  an  expression,  called  a  (Skolem)  func¬ 
tion  instance,  consisting  of  a  new  function  letter 
and,  as  arguments,  all  variables  which  have  uni¬ 
versal  quantifiers  to  the  left  of  the  pertient  exis¬ 
tential  quantifier.  A  new  constant,  i.e.,  0-ary 
function,  is  associated  with  any  existentially 
quantified  variable  whose  quantifier  precedes  all 
universal  quantifiers.  After  all  appropriate  func¬ 
tion  instances  are  formed,  drop  all  quantifiers 
and  then  for  every  variable  occurrence  which 
has  an  associated  function  instance  (i.e.,  any 
variable  previously  existentially  quantified)  re¬ 
place  the  variable  by  its  associated  function  in¬ 
stance.  For  example,  3xVy3zVwP(x,y,z,w)  be¬ 
comes  P(a,y,f(y),w)  where  P  is  a  quantifier  free 
formula  not  containing  the  constant  a  or  the 
function  symbol  f. 

Example  (cont’d.):  From  (14): 

(15)  ~[~[~A(x)  V  B(x)  ]  V  [~A(a)  V  B(z)  ]  ], 
where  a  is  a  constant. 


Step  6.  Simplify,  if  a  formula  from  step  5  con¬ 
tains  a  clause  with  both  an  atom  and  its  negation, 
the  clause  may  be  eliminated.  A  second  occur¬ 
rence  of  a  literal  in  a  clause  may  also  be  elimi¬ 
nated.  If  a  clause  C  exists  which  contains  all  the 
literals  of  another  clause  and  perhaps  more,  then 
clause  C  can  be  eliminated.  (Stronger  than  this 
last  condition  is  the  rule  that  any  subsumed 
clause  can  be  eliminated,  but  it  is  desirable  to 
defer  the  definition  of  clause  subsumption.)  As 
an  example  of  simplification, 

P(X)  &  [Q(x)  V  ~  P(y)  V  Q(x)]  &  [R(x)  V  ~  R(X)] 


Step  5.  Place  in  conjunctive  normal  form.  To  de¬ 
fine  conjunctive  normal  form  it  is  convenient  to 
introduce  some  useful  terminology.  An  atomic 
formula,  or  atom,  is  a  predicate  instance,  i.e„  a 
predicate  letter  followed  by  its  arguments,  which 
are  terms.  A  literal  is  an  atom  or  its  negation.  A 
disjunctive  clause,  or  simply  clause,  is  a  disjunc¬ 
tion  of  literals.  For  example,  ~  P(x)  V  Q(x,y)  V  ~ 
R(y)  is  a  clause  of  three  literals.  A  quantifier-free 
formula  (qff)  is  in  conjunctive  normal  form  (cnf) 
if  it  is  the  conjunction  of  clauses.  Thus  P(x)  & 
~  Q(y)  &  (R(y)  V  ~  R(X)  is  in  cnf.  A  qff  is  placed 
in  cnf  by  appropriate  use  of  the  following  trans¬ 
formations: 

(a)  ~  (AVB)  to  ~  A  &  ~  B,  ~  (A  &  B)  to 

~  AV~  B, 

(b)  A  V  (B  &  C)  to  (AVB)  &  (A VC), 

(c)  - A  to  A. 

Recall  that  V  and  a  are  commutative  and  asso¬ 
ciative. 

Example  (cont’d.):  A  sequence  of  transforma¬ 
tions  takes  (15)  into  a  for¬ 
mula  (16)  in  cnf. 

~  ~  [  'A(x)  V  B(x)]  &  ~  (~A(a)  V  B(z)j  by  (a) 

[~A(x)  V  B(x)  ]  &  ~  j~A(a)  V  B(z)j  by  (c) 

[~A(x)  V  B(x)j  & - A(a)  &  ~B(z)  by  (a) 

(16)  [~A(x)  V  B(x)j  &  A(a)  &  ~B(z)  by  (c) 


can  be  simplified  to 


&  [P(x)  V  Q(y)j 


P(x)  &  [Q(x)  V  ~  P(y )] . 
Example  (cont’d.):  step  6  introduces 
on  (16). 


no  change 


Step  7.  Reduce  notation.  We  shift  to  a  set  nota¬ 
tion  from  a  formal  language  notation  and  take 
advantage  of  the  commutivity  and  associativity  of 
&  and  V.  Each  clause  is  treated  as  a  set  of 
literals;  the  V  symbol  is  dropped.  However,  the 
standard  brace  couplet  {  }  denoting  the  boundary 
of  the  membership  list  is  omitted.  Literals  of 
the  same  clause  are  simply  listed  adjacent  to 
one  another  with  no  separating  symbol.  It  is 
convenient  to  omit  parentheses  and  commas  from 
atoms  also,  writing  Rf(xy)xy  for  R(f(x,y),x,y),  for 
example.  Thus,  for  instance,  the  clause  R(g(x),y) 
V  Q(a,f(a,y) )  is  rewritten  Rg(x)y  Qaf(ay).  The 
formula  itself  is  altered  to  read  as  a  set  of 
clauses.  The  bracket  delimiters  are  sometimes 
used  with  clauses  separated  by  commas.  Often 
formulas  are  presented  by  displaying  one  clause 
per  line  with  the  clauses  on  successive  lines  and 
the  bracket  delimiters  omitted. 

Example  (cont’d.):  (16).  becomes: 

(17)  ~  Ax  Bx 

(18)  Aa 

(19)  ~  Bz 
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A  formula  presented  as  given  at  step  6  or  step 
7  is  said  to  be  in  Skolem  functional  form  The 
manipulations  of  steps  1,  2,  3,  and  5  do  not  alter 
unsatisfiability  because  logical  equivalences  are 
involved^  The  introduction  of  Skolem  functions 
at  step  4  preserves  only  the  property  of  havinq 
no  model  (unsatisfiability)  or  at  least  one  mode? 
The  Skolem  function  can  be  regarded  as  the 
verifying  function  for  the  existential  quantifier 
making  the  formula  true  (in  an  interpretation)  if 
and  only  if  there  exists  an  individual  making  it 
true.  The  individual  would  clearly  depend  on 
those  variables  universally  quantified  within 
whose  scope  the  existential  quantifier  lies. 

A  theorem  within  a  first  order  theory  with  a 
finite  number  of  axioms  is  easily  converted  to 
Skolem  functional  form  as  each  axiom  may  be 
converted  individually.  Then  the  resultant  clauses 
plus  the  negation  of  the  theorem  statement  forms 
the  appropriate  formula  for  input.  Thus  the  list 
of  thirteen  axioms  and  the  negation  of  the  asser- 
hon  m  Figure  1  presents  the  monkey-banana 
prob  em  in  input  form.  The  group  axioms  (7),  (8) 
and  (9)  in  Skolem  functional  form  are- 

/onv  .a  »  * 


from  (7) 
from  (8) 
from  (8) 
from  (9) 
from  (9) 


(20)  Pxyf(xy) 

(21)  —  Pxyu  ~  Pyzv  ~  Pxvw  Puzw 

(22)  ~  Pxyu  ~  Pyzv  ~  Puzw  Pxvw 

(23)  Peyy 

(24)  Pg(y)ye  Trom 

If  suffices  to  add  the  Skolem  functional  form  of 
the  negation  of  the  assertion  of  a  group  theory 
theorem  (and  perhaps  special  hypotheses  as 
axioms)  to  present  a  group  theory  problem.  As 
an  example  consider 

(25)  ~  Pag(a)e 

which  arises  from  the  negation  of  VxPxg(x)e. 
VxPxg(x)e  asserts  that  the  left  inverse  function  g 
(introduced  as  a  Skolem  function)  is  also  a  riqht 
inverse  function.  a 

Sometimes  a  more  desirable  conversion  can 
be  obtained  by  introducing  Skolem  functions  be¬ 
fore  obtaining  a  prenex  normal  form. 


2.  The  Basic  Operation  of  Resolution 

Resolution  can  be  characterized  as  the  cut 
inference  rule  (or  a  generalized  modus  ponens 
inference  ru|e)  0f  propositional  logic  with  an 
appropriate  substitution  rule.  Alternately  one 

"Turn0"  iS  based  on  the  ‘autology 
(  AVC  &  (~  CVB)  D  AVB).  Consider  the  propo¬ 
sitional  part  of  resolution  first.  Two  literals  are 
complementary  if  one  difiers  from  the  other  only 
by  possession  of  a  negation  sign.  Px  and  ~  Px 

levep.CroPleme[1tary  li,eralS-  Af  ,he  propositional 
level  the  resolution  operation  takes  two  parent 

CldUS6S  A|A?  .  A  and  R  R  d  u  • 

'v  n  ana  B*B?  •  •  .  Bm  sharing  a 
complementary  pair  of  literals,  the  literals  re- 
so  ved  upon,  say  B|  =  ~  A|1  and  yields  the  re¬ 
solvent  clause  AA  .  .  .  A„B2  .  .  .  Bm.  (For  formula 
nota  ion  see  section  1,  step  7).  That  is,  the  literal 
resolved  upon  in  each  clause  is  deleted  and  the 
remaining  literals  comprise  the  resolvent  It  is 
always  assumed  that  no  two  literals  of  a  clause 
are  identical.  Thus  B„  k  >  2,  is  omitted  from  ex¬ 
plicit  appearance  if  B,  =  A„  for  some  i  >  2. 

Substitution  is  used  to  form  a  complementary 
pair  between  two  clauses  when  none  exists  ex¬ 
plicitly.  For  example,  PxRu  and  ~  pf(y)Qu  are 
two  clauses  not  qualified  for  resolution  as  given 
above,  but  by  replacing  the  x  by  f(y)  clauses 
Pf(y)Ru  and  ~  Pf(y)QU  can  be  resolved  to  get 
RuQz  Note  that  the  variable  u  in  PxRu  is  not 
identified  with  the  u  of  ~  Pf(y)Qu.  At  the  begin¬ 
ning  of  the  resolution  operation  variables  are  re- 
named  so  no  variaWe  is  named  in  both  clauses. 
The  substitutions  are  always  made  uniformly  at 

cou°sCeCUrrenCeS  °f  3  Variable  in  anV  clause,  of 

Let  rj  =  A,A?  .  .  .  A„  and  73  =  B,B,  .  .  .  B  rep¬ 
resent  two  clauses,  with  A;  and  B,  two  literals, 
one  from  each  clause.  The  resolvent  of  nj  and  ‘73 

fol!owsSPeCt  ,0  A'  and  B‘'  if  if  eXiStS’  iS  f0Und  as 


I 

J 

i 
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(1)  Check  if  A,  and  Bk  have  the  same  predicate 
letter  and  precisely  one  has  a  negation 
sign.  Halt,  if  this  is  not  the  case,  since  no 
resolvent  clause  with  respect  to  A,  and  Bk 
exists.  Otherwise,  proceed. 

(2)  Change  variable  names  of  <B  as  necessary 
so  that  no  variable  name  is  shared  by  c A 
and  B. 

(3)  Match  |A,|  and  |Bk|,  the  atoms  of  A,  and  Bk, 
respectively  by  appropriate  substitutions  in 
each  literal  (the  matching  procedure  is  out¬ 
lined  below).  If  the  matching  is  unsuccess¬ 
ful,  no  resolvent  exists,  so  halt.  Otherwise, 
make  the  appropriate  substitutions  through 
oA  and  <B  so  thatch'  and  B'  are  substitution 
instances  of  and  B  and  Ai  and  Bk  are  the 
complementary  literals  determined  by  the 
matching  procedure. 

(4)  Form  the  resolvent  by  deleting  A/  and  Bk' 
and  putting  the  remaining  literals  of  C/T  and 
B'  minus  redundancies  in  a  single  clause 
(as  demonstrated  above). 

The  matching  procedure  between  atoms  |A,| 
and  |Bk|  finds  a  substitution  instance  for  each 
atom  to  make  them  identical  if  such  a  substitu¬ 
tion  exists.  The  substitution  obtained  is  in  a  suit¬ 
able  sense  the  most  genera!  substitution  possible, 
an  important  property  for  attaining  complete  proof 
procedures.  This  can  be  performed  as  follows. 
Let  |A,|  and  Bk|  share  no  variable  names.  The 
atoms  are  considered  written  as  on  paper  in  the 
notation  adopted,  all  symbols  in  sequence. 

(a)  Set  a  pointed  at  the  predicate  letter  of  JAj| 
and  a  pointer  at  the  predicate  letter  of  |B„|. 

(b)  Move  the  pointers  in  parallel  to  the  right 
one  symbol  at  a  time  (including  parenthe¬ 
ses  if  present).  Stop  at  the  first  place  the 
pointers  point  to  different  symbols.  If  the 
end  is  (simultaneously)  reached  first,  the 
atoms  match;  exit.  Otherwise,  proceed 
to  (c). 


(c)  If  one  pointer  points  to  a  parenthesis,  or 
precisely  one  pointer  has  come  to  the  end, 
there  is  a  notational  error  (this  shouldn’t 
occur).  If  neither  pointed  points  to  a  vari¬ 
able,  match  attempt  fails;  exit.  If  one 
pointer  points  to  a  function  letter,  search 
the  function’s  arguments  for  an  occurrence 
(at  any  depth)  of  the  variable  indicated  by 
the  other  pointer.  If  an  occurrence  exists, 
match  fails;  exit.  In  all  other  cases,  re¬ 
place  the  variable  v  at  one  pointer  by  the 
the  term  whose  first  symbol  is  indicated 
by  the  other  pointer.  The  replacement  oc¬ 
curs  at  all  occurrences  of  v  in  both  literals. 
The  two  pointers  now  agree.  Return  to  (b). 

As  an  example,  consider  matching  Pxf(y)  and 
Pg(ww)w.  A  match  exists,  the  common  atom  is 
Pg(f(y)f(y))f(y),  whereas  Pxf(y)  and  Pyf(g(x))  do 
not  match.  This  latter  example  serves  to  empha¬ 
size  that  the  variable  renaming  that  is  part  of  the 
resolution  operation  is  not  part  of  the  matching 
operation. 

One  other  necessary  notion  is  that  of  a  factor 
of  a  clause.  A  factor  of  clause  c 4  is  a  substitution 
instance  cA'  of  <A  determined  by  finding  a  match 
between  two  atoms  of  the  clause  that  makes  the 
two  corresponding  literals  of  c A  identical.  Thus 
QaPf(a)a  is  a  factor  of  QxPf(x)xPya.  Note  that 
here  variables  are  not  renamed  to  make  each 
literal  have  distinct  variables  as  substitutions  are 
always  uniform  throughout  clauses.  Thus  Pf(a)a 
is  not  a  factor  of  Pf(x)xPxa.  A  factor  of  a  factor 
of  c//  is  defined  to  be  a  factor  of  zA,  Clearly  a 
clause  has  only  a  finite  number  of  factors.  Ex¬ 
ample  1  below  shows  factoring  is  necessary  for 
completeness.  No  refutation  (see  below)  exists 
without  factoring. 
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The  basic  resolution  procedure  proceeds  as 
follows.  Start  with  the  set  of  given  clauses  as 
the  "present”  set. 

Form  all  possible  resolvents  of  clauses  of  the 
present  set  and  their  factors.  If  the  empty 
clause  □  (the  clause  with  not  literals,  the 
resolvent  of  two  one-literal  parent  clauses) 
is  formed,  the  given  set  represents  an  un- 
satisfiable  formula.  Otherwise,  delete  all 
tautologies  (clauses  with  complementary  lit¬ 
erals).  Define  the  remaining  clauses  as  the 
present  set  and  return  to  the  beginning  of 
this  paragraph. 

Each  cycle  of  these  instructions  generates  a  new 
level  of  resolvents.  The  level  of  a  clause  is  de¬ 
termined  by  the  level  of  its  first  appearance.  The 
calculation  of  all  resolvents  and  factors  of  a 
given  level  at  once  is  called  a  level  saturation 
search. 

The  need  for  factors  is  seen  from  applying  the 
resolution  operation  alone  to  the  two  member 
unsatisfiable  set  S  of  clauses  given  by  S  = 
{PuPv,  ~  Px  ~  Py}.  Although  clearly  unsatisfi¬ 
able  (replace  u,v,x,y  by  a)  the  resolvents  are  all 
two  literal  clauses.  However,  □  is  derived  in  the 
first  cycle  of  the  basic  resolution  procedure,  thus 
□  “occurs  at  level  1”.  See  Examp's  1  below. 

The  justification  for  the  correctness  (sound¬ 
ness)  and  sufficiency  (completeness)  of  the  above 
procedure  and  those  that  follow  come  from  the 
theorem  due  to  Herbrand:  If  S  is  a  formula  in 
Skolem  functional  form  then  S  is  unsatisfiable  if 
and  only  if  there  exist  clause  substitution  in¬ 
stances  C, . Cn  such  that  C,  &  C,  &  .  .  .  &  C„ 

is  unsatisfiable. 


Three  examples  follow  of  deductions  of  □,  two 
of  which  are  from  examples  of  section  1.  A 
resolution  deduction  of  clause  C  is  a  sequence 
of  clauses,  each  a  (substitution)  instance  of  a 
clause  of  the  given  set  S,  a  factor  of  a  preceding 
clause,  or  a  resolvent  of  two  preceding  clauses 
of  the  deduction  and  with  last  clause  C.  A  de¬ 
duction  of  □  is  called  a  refutation. 


Example  1:  A  refutation  of  {PuPv,  ~  Px  ~  Py}: 


PuPv 
~  Px  ~  Py 
Pu 
~  Px 

□ 


given 
given 
factor  of  1 
factor  of  2 
resolvent  of  3,4 


Example  2:  A  refutation  of  (11)  of  section  1  which 
in  Skolem  functional  form  appears  as 
clauses  (17),  (18),  (19): 

1.  ~  Ax  Bx  (17) 

2.  Aa  (18) 

3.  ~  Bi  (19) 

4.  Ba  resolvent  of  1,2 

•5.  □  resolvent  of  3,4 


Example  3:  A  refutation  of  the  set 
(20)  —  (25),  section  1  : 

1.  Pxyf(xy) 

2.  ~  Pxyu  ~  Pyzv  ~  PxvwPuzw 

3.  ~  Pxyu  ~  Pyzv  —  PuzwPxvw 

4.  Peyy 

5.  Pg(y)ye 

6.  ~  Pag(a)e 

7.  ~  Pxya  ~  Pyg(a)v  ~  Pxve 

8.  ~  Pg(v)ya  ~  Pyg(a)v 

9.  ~  Pg(g(a))ea 

10.  ~  Pg(g(a))yu  ~  Pyze  ~  Puza 

11.  ~  Pg(g(a))ye  ~  Pyae 

12.  ~  Pg(g(a))g(a)e 

13.  □ 


of  clauses 

(20) 

(21) 

(22) 

(23) 

(24) 

(25) 

resolvent  of  6,2 
resolvent  of  7,5 
resolvent  of  8,4 
resolvent  of  9,3 
resolvent  of  10,4 
resolvent  of  1 1 , 
resolvent  of  12, 


The  reader  can  quickly  check  that  axioms  (i) 
through  (xiii)  together  with  the  negation  of  the 
assertion  for  the  monkey-banana  problem  define 
a  set  of  clauses  which  yields  a  refutation. 


cn  cn 
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3.  The  Unit  Preference  and  Set-of-Support 
Strategies 

Perhaps  the  earliest  strategy  to  be  applied  to 
resolution  is  the  unit  preference  strategy.  The 
basic  idea  is  simple:  resolve  with  one-literal 
(i.e.,  unit)  clauses  more  often  than  called  for  by 
the  basic  resolution  procedure,  One  can  indeed 
demand  that  the  only  resolution  operations  al¬ 
lowed  will  be  when  at  least  one  clause  is  a  unit 
clause.  This  may  prevent  finding,  even  theoreti¬ 
cally,  some  refutations  (i.e.,  this  is  not  a  complete 
process)  but  many  sets  of  clauses  can  be  shown 
unsatisfiable  in  this  way  with  a  great  gain  in 
search  time  over  the  basic  procedure.  Complete¬ 
ness  is  regained  if  the  process  intermittently 
forms  the  resolvents  of  various  pairs  of  non-unit 
clauses  so  that  eventually  each  level  of  resolv¬ 
ents  is  completed.  Examples  1,  2,  and  3  of  the 
preceding  section  are  “unit”  proofs,  i.e.,  have  no 
resolvents  of  two  non-unit  clauses. 

The  set-of-support  strategy  sharply  limits  the 
clauses  obtained  at  the  first  level  by  the  basic 
resolution  procedure.  Let  S  denote  the  given  set 
of  clauses  (e.g.,  lines  1-6,  example  3)  and  T  be 
any  satisfiable  subset  of  S  (e.g.,  lines  1-5,  ex¬ 
ample  3).  The  set-of-si'Dport  strategy  states  that 
two  clauses  of  T  are  not  to  be  resolved  together. 
A  deduction  under  such  constratint  is  said  to  “have 
set-of-support  S-T”.  Example  3  is  a  refutation 
with  set-of-support  S-T  where  S-T  contains  only 
clause  6.  The  set-of-support  strategy  is  complete. 
It  is  often  used  in  conjunction  with  the  unit 
preference  strategy. 

A  very  useful  rule  is  the  subsumption  principle. 
Discard  any  clause  C  if  there  exists  a  clause  D 
with  a  substitution  instance  D'  such  that  every 
literal  of  D'  is  a  literal  of  C.  For  example,  Px 
subsumes  PaQb  so  the  latter  should  be  discarded 
in  the  presence  of  Px, 

Another  rule  of  some  usefulness,  the  purity 
rule,  states  that  any  clause  may  be  discarded  if 
it  contains  a  literal  with  no  complement  among 
the  substitution  instances  of  the  given  set  of 
clauses.  Both  rules  are  applicable  to  the  com¬ 
bined  unit  preference,  set-of-support  strategy. 


4.  Partition  Strategies 

Let  S  be  a  given  set  of  clauses.  Let  M  be  a 
set  of  literals  such  that  no  two  literals  have  sub¬ 
stitution  instances  which  are  complementary.  We 
call  M  a  setting.  Thus  {Px,  ~  Rf(y)}  is  a  setting 
but  {Px,  ~  Pf(y) }  is  not.  A  setting  is  a  partition 
M,  of  S  if  every  literal  of  (a  clause  of)  S  is  identi¬ 
cal  to,  or  a  complement  of,  a  substitution  instance 
of  a  literal  of  Mv  Examples  of  partitions  of  S  are 
(1)  the  set  of  all  atoms  of  S  and  (2)  the  set  of 
negations  of  all  atoms  of  S.  A  partition  strategy 
is  a  resolution  procedure  where  one  parent  clause 
of  every  resolution  operation  contains  no  literal 
which  is  a  substitution  instance  of  a  literal  of  M.. 
Such  a  clause  is  called  false  in  Ms.  Example  3  of 
section  2  is  a  refutation  realizable  within  the 
partition  strategy  where  M,  is  the  set  of  all  atoms 
of  the  given  set  S.  Therefore,  one  parent  clause 
of  each  resolution  operation  contains  only  ne¬ 
gated  atoms  in  this  example.  Partition  strategies 
are  complete  for  any  choice  of  partition.  Unit 
preference  can  be  combined  with  partition  strate¬ 
gies,  often  to  advantage,  with  completeness  main¬ 
tained.  A  set-of-support  strategy  generally  does 
not  combine  with  a  partition  strategy  to  maintain 
completeness.  However,  a  partition  strategy  can 
be  regarded  as  a  generalized  set-of-support  itself. 
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Ordering  strategies  can  be  superimposed  on  a 
partition  strategy.  This  is  highly  effective  in  some 
cases  and  preserves  completeness.  For  example, 
if  the  set  S  contains  many  predicate  letters  (such 
as  occurs  in  information  retrieval  systems),  assign 
an  order  to  the  predicate  letters.  Order  all  clauses 
that  are  false  in  M,  by  ordering  on  predicate 
letters  with  the  symbol  <  (less  than),  also  read 
“to  the  left  of;”  in  every  other  clause  form  ihe 
maximal  length  subclause  false  in  Ms  ordered  by 
tiie  predicate  letter  ordering.  Place  any  remain¬ 
ing  literals  of  the  clause  after  (to  the  right  of) 
the  ordered  subclause;  these  literals  may  be 
placed  in  any  desired  order  among  themselves. 
If  any  clause  false  in  Mk  has  several  literals  each 
of  which  could  be  rightmost,  the  clause  is  listed 
once  for  each  of  these  “equal"  literals  with 
that  literal  occurring  farthest  right.  A  resolution 
operation  is  performed  only  if  the  rightmost  literal 
of  each  clause  is  the  literal  resolved  upon  (also, 
of  course,  only  if  one  parent  is  false  in  Mk).  The 
resolvent  is  ordered  as  above.  An  example  of  a 
refutation  realizable  within  this  combined  strategy 
is  given  below. 


Example  4:  The  given  set  S  of  clauses  is  listed 
in  lines  1,  3-6.  M,  is  the  set  of  all 
negations  of  atoms  of  S.  Note  that 
line  2  gives  the  same  clause  as  line  1 
(clause  1  is  false  in  Mk).  The  ordering 
of  predicate  letters  is  A  <  B. 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 

10. 

11. 

12. 


Aa  Ab 
Ab  Aa 
Ax  Bx  ~  Aa 
Ax  ~  Aa  ~  Bx 
Aa  ~  Ax 

-  Aa  ~  Ab 
Aa 

Ax  Bx 
Ax  ~  Aa 
Ax 

-  Aa 

□ 


given  clause 
clause  1,  alternate  order 
given  clause 
given  clause 
given  clause 
given  clause 
resolvent  of  1,5 
resolvent  of  7,3 
resoivent  of  8,4 
resolvent  of  9,7 
resolvent  of  10,6 
resolvent  of  11,7 


5.  Linear  Resolution  Strategies 

The  strategies  considered  in  this  section  differ 
essentially  from  the  preceding  strategies  which 
were  oriented  towards  modifying,  but  not  drasti¬ 
cally  altering,  the  level  saturation  search  of  basic 
resolution.  Linear  resolution  is  depth  oriented 
with  little  interaction  between  clauses  at  a  given 
level.  The  definition  is  best  given  in  terms  of  a 
deduction  (defined  a.‘  the  end  of  section  2). 

A  linear  (resolution)  deduction  T)  of  clause  Bn 

is  a  resolution  deduction  B . B„  where  B," 

1  <  i  <  k  is  a  member,  or  a  factor  of  a  member, 
of  the  given  set  S  and  Bk„,  1  <  i  <  n-k,  is  either 
a  resolvent  with  Bkli_|  as  ons  parent  clause,  called 
the  near  parent,  or  (Bkti  is)  a  factor  of  Bkfl_„  If 
Bk.i  is  a  resolvent  then  the  far  parent  of  Bkli  must 
must  be  a  Bm,  or  a  factor  of  Bm,  for  some  m<k+i. 
The  initial  sequence  B„ , .  Bk  of  <D  is  called  the 
prefix  of  <T>.  Although  the  definition  of  linear 
deduction  just  given  allows  a  far  parent  to  be  a 
factor  riot  explicitly  appearing  in  the  deduction, 
it  can  be  shown  that  completeness  is  preserved 
and  little  flexibility  lost  if  such  an  implicit  factor¬ 
ing  is  disallowed.  A  linear  refutation  is  a  linear 
deduction  of  □.  Example  3  (section  2)  is  a  linear 
refutation  and  Example  2  would  be  if  lines  1  and 
3  were  interchanged.  It  might  be  instructive  for 
the  reader  to  find  a  linear  refutation  for  the  given 
set  of  Example  1. 

A  more  restrictive  complete  resolution  strategy 
is  that  of  s-linear  resolution  (so-called  because 
the  added  restriction  can  be  expressed  in  terms 
of  a  subsumption  condition).  An  s-linear  refuta¬ 
tion  T)  is  a  linear  refutation  with  the  following 
restriction:  the  far  parent  of  a  resolvent  is  either 
chosen  from  the  prefix  of  ‘ D  or  is  chosen  from 
ID  so  that  a  certain  modilied  resolvent  is  formed. 
The  modilied  resolvent  must  be  a  factor  of  the 
usual  resolvent  and  also  a  substitution  instance 
of  the  near  parent  clause  minus  its  literal  re¬ 
solved  upon.  For  example,  if  the  near  parent 
clause  is  AxByCz,  then  the  clause  Aa  ~  Cb  is  an 
acceptable  far  parent  clause  even  if  not  in  the 
prefix  of  V  for  then  take  AaBy,  a  factor  of 
resolvent  AxByAa,  as  the  modified  resolvent.  If 
a  modified  resolvent  exists,  in  general  it  can  be 
found  by  factoring  the  resolvent  on  the  literals 
that  arise  from  the  far  parent,  as  done  above. 


The  process  of  finding  modified  resolvents  is 
more  complex  than  finding  standard  resolvents, 
but  fewer  far  parents  are  now  acceptable  which 
prunes  the  search  space  of  deductions  nt  any 
given  depth  of  search.  Example  5  below  is  an 
s-linear  refutation  where  lines  8  and  11  satisfy 
the  modified  resolvent  condition.  (Line  8  is  also 
permitted  because  the  far  parent  is  in  the  prefix 
of  the  deduction.) 

A  strategy  called  merging  may  be  superim¬ 
posed  on  s-linear  refutation.  A  resolvent  of  two 
clauses,  neither  a  tautology,  is  called  a  merge 

resolvent  with  merge  literals  L . Ln,  n  >  1,  if 

and  only  if  the  substitution  instances  of  the  two 
parents  which  form  the  resolvent  propositionally 
each  have  L„  . . .,  Ln  as  literals.  Thus  AaBf(a)  is 
a  merge  resolvent  of  AaByAg(x)  and  AxBf(x)  ~  Ay. 
Note  that  the  ordinary  resolvent  is  AaByAxBf(x), 
so  here  a  further  substitution  is  necessary  to 
produce  a  merge  resolvent  with  merge  literals 
Aa  and  Bf(a).  The  merge  condition  is  added  to 
s-linear  resolution  in  the  following  way.  If  the 
far  parent  is  not  a  member  of  the  prefix  of  T), 
it  must  be  a  merge  resolvent  with  a  merge  literal 
as  the  literal  resolved  upon  (in  addition  to  the 
s-linear  resolution  requirement). 

As  with  the  strategies  of  the  preceding  sec¬ 
tions,  tautologies  need  not  be  used.  However, 
there  are  some  sets  S  for  which  there  is  a  clause 
C  such  that  if  C  is  the  first  near  parent  clause, 
then  there  exists  a  refutation  of  S  “from  C"  if 
and  only  if  tautologies  are  permitted.  However, 
a  “set-of-support"  condition  holds.  If  S-  {C}  is 
satisfiable  and  S  is  unsatisfiable,  then  there  exists 
a  refutation  from  clause  C  in  any  of  the  strategies 
considered  in  this  section  with  no  tautology 
appearing. 
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There  are  further  conditions  which  can  be  im¬ 
posed  on  s-linear  resolution.  A  deduction  is 
tight  if  and  only  if  no  clause  subsumes  (see  sec¬ 
tion  3  a  later  clause  in  the  deduction.  An  s-linear 
deduction  is  an  ordered  clause  deduction  if  all 
clauses  are  ordered  (say,  left  to  right  when  writ¬ 
ten)  and  every  literal  resolved  on  for  near  parent 
clauses  and  every  literal  factored  is  the  rightmost 
literal  of  that  clause.  This  last  definition  omits 
some  technicalities  (and  improvements)  which  do 
not  seriously  alter  the  nature  of  the  strategy.  A 
version  of  merging  can  be  incorporated  with 
these  strategies  so  that  completeness  is  retained. 

Example  3  gives  a  tight  ordered  clause  deduc¬ 
tion  with  line  6  as  first  near  parent  clause.  The 
prefix  is  lines  1-6.  Notice  all  far  parents  are 
members  of  the  prefix.  Such  a  refutation  is  called 
an  input  refutation.  One  of  the  more  interesting 
results  of  resolution  theory  states  that  S  has  an 
input  refutation  if  and  only  if  it  has  a  unit  clause 
refutation.  In  general  they  are  not  the  same  re¬ 
futation. 

We  give  as  Example  5  a  tight  ordered  clause 
refutation  with  the  merging  condition  that  is  not 
an  input  refutation. 


i 
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Example  5:  The  given  set  of  clauses  Is  that  of 
Example  4  and  appears  on  lines  1-5. 
Lines  1-5  needn't  be  considered  or¬ 
dered  clauses  as  there  is  no  order 
condition  on  the  far  parent.  Line  5 
is  considered  ordered  when  viewed 
as  first  near  parent,  however. 


1. 

Aa  Ab 

given 

2. 

~  Aa  Ax  Bx 

given 

3. 

~  Bx  Aa  Ax 

given 

4. 

Ax  Aa 

given 

5. 

~  Aa  ~  Ab 

given 

6. 

~  Aa  Bb 

resolvent  of  5,2 

7. 

~  Aa  Ab 

resolvent  of  6,3 

8. 

~  Aa  merge  literal, 

resolvent  of  7,5 

9. 

Ab 

resolvent  of  8,1 

10. 

Aa 

resolvent  of  9,4 

11. 

□ 

resolvent  of  10, 
line  8 
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The  far  parent  condition  of  s-linear  resolution 
and  the  tightness  conditions,  though  strong,  are 
expensive  to  check  because  in  general  several 
matchings  need  be  checked  per  candidate.  This 
costly  multiple  matching  can  be  reduced  to  single 
matching  by  altering  the  resolution  format  of  a 
tight  ordered  clause  strategy  in  the  following 
manner.  When  performing  a  resolution  operation 
instead  of  deleting  the  rightmost  literal  of  the 
near  parent  clause,  retain  it  as  a  distinguished 
literal  (we  shall  indicate  such  literals  with  bold¬ 
face)  and  add  the  far  parent  minus  the  literal 
resolved  upon  to  the  right  as  before.  Any  literal 
identical  to  a  near  parent  literal  is  not  added,  A 
new  optional  operation  (reduction)  is  added  also. 
If  a  distinguished  literal  can  be  made  complemen¬ 
tary  to  the  rightmost  literal  in  the  clause,  one 
forms  the  (ordered)  clause  with  the  appropriate 
substitution  but  with  the  rightmost  literal  deleted. 
Finally,  one  always  deletes  distinguished  literals 
to  the  right  of  the  rightmost  ordinary  literal  as 
soon  as  that  condition  occurs  within  any  opera¬ 
tion.  Example  6  gives  the  same  refutation  as 
Example  5  in  the  new  notation. 


Example  6: 

1. 

Aa  Ab 

given 

2. 

Ax  Bx  ~  Aa 

given 

3. 

Ax  —  Aa  ~  Bx 

given 

4. 

Aa  ~  Ax 

given 

5. 

~  Aa  ~  Ab 

given 

6. 

~  Aa  ~  Ab  Bb 

far  parent,  2 

7. 

~  Aa  ~  Ab  Bb  Ab 

far  parent,  3 

8. 

~  Aa 

reduction 

9. 

~  Aa  Ab 

far  parent,  1 

10. 

~  Aa  Ab  Aa 

far  parent,  4 

11. 

□ 

This  strategy  actually  is  a  special  type  of  model 
elimination  procedure  developed  independently 
of  resolution  theory.  There  is  more  to  that  pro¬ 
cedure  than  outlined  here,  including  some  tests 
for  rejection  of  bad  deductions,  use  of  “lemmas," 
etc.  This  can  all  be  regarded  as  a  refinement  of 
linear  resolution. 


6.  Implementation 

Some  variation  of  each  of  the  strategies  men¬ 
tioned  here  has  been  realized  on  the  computer. 
To  the  author’s  knowledge,  no  strategy  of  any  of 
the  three  categories  (sections  3,  4,  and  5)  has 
uniformly  dominated  the  others.  For  example, 
the  s-linear  resolution  strategy  (actually  in  model 
elimination  format)  has  given  some  dramatic  re¬ 
sults  in  search  speed  in  cases  where  refutation 
existed  by  chance  near  the  beginning  of  its 
search  space  (actually  not  too  infrequent  an 
occurrence  because  of  multiple  proof  paths)  but 
it  can  be  equally  unlucky  and  get  “lost”  In  a 
search  of  outwaidly,  the  "same  size.”  The  modi¬ 
fied  level  saturation  types  seem  to  be  more  uni¬ 
form  in  their  performance,  not  reaching  either 
extreme. 

Completeness  is  not  the  final  criterion  of  de¬ 
sirability  for  implementation,  it  is  useful  to  know 
that  when  one  piles  the  merging  condition  on 
top  of  tightness,  plus  ordering,  on  top  of  s-linear- 
ity  on  top  of  linearity  that  the  result  is  a  complete 
procedure,  for  at  first  glance  it  might  seem  un¬ 
likely  to  yield  a  single  refutation.  However,  per¬ 
formance  is  the  final  arbiter.  With  this  mind, 
programs  exist  that  allow  the  superposition  of 
strategies  from  two  or  even  all  these  categories 
and  some  mixes  have  been  quite  beneficial  for 
some  sample  problems.  Also,  "classical”  heur¬ 
istic  procedures  can  be  superimposed.  One  can 
envision  a  GPS-type  difference  analysis  coupled 
to  a  linear  resolution  strategy,  for  example. 

Resolution  procedures  have  proved  simple 
elementary  (i.e.,  formal)  group  theory  and  ele¬ 
mentary  number  theory  problems  (the  latter  when 
appropriate  lemmas  were  given  in  the  axiom  set). 
Although  these  are  real  mathematical  problems, 
and  beyond  the  theorem  provers  of  a  decade 
ago,  they  are  homework  exercises  for  mathe¬ 
matics  majors.  Resolution  procedures  occur  in 
some  question-answerer  (q-a)  systems  as  the  in¬ 
ference  device.  Such  systems  apparently  are 
among  the  most  competent  q-a  systems  in  exis¬ 
tence.  A  system  using  resolution  strategies  has 
verified  recently  published  results  on  Boolean 
algebras  whose  proofs  were  not  totally  trivial. 


7.  Credits 

The  intent  in  this  section  is  not  to  name  all 
the  people  who  have  contributed  to  aspects  of 
resolution  theory  summarized  above  but  to  name 
some  who  have  their  names  associated  with  spe¬ 
cific  items  highlighted  here.  J.  A.  Robinson 
(about  1965)  introduced  basic  resolution;  also  P, 
deduction  and  Hyper-resoiution,  which  were  the 
earliest  and  most  basic  partition  strategies.  Pra- 
witz  in  1960  outlined  the  notion  of  matching  for 
proof  procedures.  Wos,  G.  Robinson  and  Carson 
introduced  unit  preference  and  set-of-support. 
Slagle.  Luckham,  and  Meltzer  independently 
worked  with  partition  strategies.  Slagle,  and,  in¬ 
dependently,  Kowalski  and  Hayes,  superimposed 
the  order  strategy  on  partition  resolution.  The 
author  and  Luckham  independently  introduced 
linear  resolution.  S-linear  resolution  and  model 
elimination  are  the  author’s.  Merging  is  due  to 
Andrews.  Chang  discovered  the  relationship  be¬ 
tween  unit  and  prefix  resolutions.  Anderson, 
and  independently  Yates,  Raphael,  and  Hart 
linked  merging  and  s-linear  resolution. 
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Control  Structures 


David  A.  Fisher 

Computer  science  is  concerned  with  automata 
which  can  perform  various  operations.  These 
operations  differ  from  the  usual  functions  of 
mathematics  in  that  (here  is  a  time  interval  asso¬ 
ciated  with  each  one.  Consequently,  the  com¬ 
puter  scientist  is  concerned  with  algorithms,  l.e., 
with  sequences  of  operations  which  approximate 
functions  of  logic  in  a  finite  time,  Any  single  time 
ordered  sequence  of  operations  performed  in  an 
execution  of  an  algorithm  is  called  a  control  path. 
Those  operations  which  determine  the  control 
path(s)  to  be  followed  through  an  algorithm  are 
called  control  operations.  The  control  operations 
of  an  algorithm  together  with  the  interpretation 
rules  for  the  non-control  operations  constitute 
the  control  structure  of  the  algorithm. 

Despite  the  importance  of  control  to  computer 
science,  until  recently1  little  direct  attention  has 
been  given  to  it.  What  are  the  control  struc¬ 
tures  ox  current  programming  languages?  Are 
there  other  useful  control  structures?  How  can 

control  be  docCritvJ  fjUSAUf?  &rt  (Willi  J  IUUI.  - 
tures  be  composed,  say,  in  the  manner  of  func¬ 
tions?  Can  the  use  of  control  structures  better 
suited  to  a  task  simplify  that  task  or  expose  the 
significant  problems  of  that  task? 

No  attempt  will  be  made  to  answer  all  of  these 
questions  here.  Instead,  a  set  of  primitive  control 
operations  will  be  defined  from  which  it  is 
claimed  all  others  can  be  formed  by  composition, 
A  few  specialized  control  structures  will  then  be 
defined  by  composition  of  these  primitives. 

A  set  of  primitive  control  operations  should  be 
large  enough  to  span  the  space  of  control  struc¬ 
tures  but  small  enough  to  be  manageable.  Care 
must  be  exercised  with  the  first  requirement.  It 
might  be  concluded  that  sequential  processing 
and  a  conditional  control,  the  only  control  struc¬ 
tures  of  the  Turing  machine,  are  sufficient.  There 
a.e,  howc/cf,  obefut  aiiJ  ii.tcicoting  prof-citico  vl 
control  structures  that  cannot  be  described  in 
terms  of  just  these  two  controls.  If  parallel  pro¬ 
cessing  were  described  by  its  simulation  using 
sequential  control  primitives  and  by  means  of 


some  scheduling  algorithm,  then,  though  one 
might  come  to  understand  parallel  processing  as 
a  particular  interleaved  execution  of  sequential 
processes,  the  idea  of  concurrent  execution 
would  not  be  conveyed.  Concurrency  is  a  con¬ 
cept  which  cannot  be  composed  purely  from 
sequential  primitives. 

Functional  notation  (e.g.,  f(x,,x2) . . .  x„)  where 
0  <  n  and  the  x/s  may  themselves  be  functional 
forms)  will  be  used  to  describe  the  primitive  con¬ 
trol  operations  and  their  compositions.  For  a 
non-control  operation  f,  f(x, ,x2, . . .  xn)  will  be 
given  the  following  interpretation:  evaluate  each 
of  the  Xi's  and  apply  the  operation  f  to  the  result¬ 
ing  values.  This  implies  that  each  of  the  argu¬ 
ments  to  a  non-control  operation  must  produce 
a  value. 

For  control  operations  the  same  notation  will 
be  usea,  but  each  operation  will  have  a  unique 
interpretation.  For  example,  the  control  operation 
i.Lgill  duChbJ  M  lute**1  f  S)  evalu¬ 
ate  c  (assumed  to  be  a  boolean  expression).  (2) 
If  the  resulting  value  is  true,  then  evaluate  x  and 
take  that  resulting  value  as  the  value  of  If.  (3) 
Otherwise  evaluate  y  and  take  that  resulting  value 
as  the  value  of  it.  In  no  case  are  both  x  and  y 
to  be  evaluated.  Note  that  to  describe  if  as  above 
the  expressions  for  x  and  y  rather  than  their 
values  are  treated  as  arguments  to  if.  Thus  the 
control  operations  are  those  operations  which 
have  expressions  as  their  arguments.  In  the 
definitions  below,  those  formal  parameter  names 
which  refer  to  expressions  are  in  boldface. 

The  controis  to  be  proposed  are  primitive  in 
the  sense  that  each  encompasses  only  a  single 
idea.  This  contrasts  with  many  of  the  specalized 
controls  (e.g.,  for  statements  of  Algoi-60)  of  cur¬ 
rent  languages,  This  makes  it  possible  to  pro¬ 
vide  actuiaie  descriptions  of  tne  othei  coiftiul 
structures  and  to  guarantee  that  composition 
will  be  meaningful,  (e.g.,  with  lor,  composition  is 
restricted  to  strict  imbedding).  The  proposed 
control  operations  follow. 
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The  Primitive  Operations 

seq(x,,x2, . . .  xn)  Sequential  processing. 

The  sequential  processing  operation  seq  causes 
its  arguments  to  be  evaluated  in  the  order  given 
from  left  to  right  in  such  a  way  that  the  evaluation 
of  an  argument  will  not  begin  until  the  evaluation 
of  all  arguments  to  its  left  are  complete.  Only 
that  value  produced  by  the  evaluation  of  x„  will 
be  taken  as  the  value  of  seq.  This  means  that 
the  purpose  of  the  evaluations  of  x,,x2, . . .  x„_, 
must  have  been  side  effects  (i.e.,  changes  they 
impose  on  the  environment).  Evaluation  for  side 
effects  only  is  usually  called  execution,  although 
we  will  use  the  terms  interchangeably. 

par(x,,x2, . . .  x„)  Parallel  processing. 

The  parallel  processing  control  operation  par 
causes  its  arguments  to  be  evaluated  indepen¬ 
dently  (i.e.,  in  parallel)  as  if  each  had  its  own 
processor.  No  assumptions  are  made  about  the 
relative  speeds  of  these  processors,  so  there 
are  no  guarantees  concerning  the  chronogolical 
order  of  their  side  effects.  These  effects  can, 
however,  be  controlled  by  the  synchronization 
of  the  parallel  control  paths  as  described  below. 
The  establishment  of  parallel  paths  has  no  spe¬ 
cial  effect  on  the  environmental  data  structure 
of  a  program.  In  particular,  copies  of  the  en¬ 
vironment  are  not  made  for  eaoh  path,  so  that 
they  must  share  the  same  global  variables  and 
define  their  own  local  variable*.  The  value  of  x„ 
is  taken  as  the  value  of  par  but  is  returned  only 
after  the  execution  of  all  the  Xj's  is  complete. 


cond(cltX|,c2,x2, . . .)  Condition  testing. 

The  conditional  operation  co nd  has  an  even 
number  of  arguments.  Beginning  with  the  left¬ 
most  argument,  every  other  argument  will  be 
evaluated  in  order  from  left  to  right  until  one 
having  value  true  is  encountered.  The  argument 
immediately  to  the  right  of  this  argument  will 
then  be  evaluated  and  the  result  taken  as  the 
value  of  co  nd.  If  none  of  the  odd  numbered 
arguments  evaluates  to  true,  the  value  of  the  ex¬ 
pression  is  undefined  and  none  of  the  even  num¬ 
bered  arguments  is  evaluated. 

monitor(c.x)  Monitoring. 

The  monitor  operation  monitor  causes  the  ex¬ 
pression  c  to  be  continuously  evaluated  until  its 
value  becomes  true.  The  valueof  c  can  change  only 
when  the  value  of  at  least  one  of  the  variables  of 
the  expression  c  is  changed  as  a  side  effect  of  a 
parallel  path.  (In  practice  c  might  be  reevaluated 
only  when  any  of  its  variables  changes.)  When 
the  value  of  c  becomes  true,  the  repetitive  evalu¬ 
ation  of  c  will  be  terminated,  the  expression  x 
will  be  evaluated,  and  the  resulting  value  taken 
as  the  value  of  monitor.  No  assumption  is  made 
about  the  relative  speeds  of  the  processors  which 
change  the  variables  of  c  and  the  processor 
which  evaluates  c.  Thus,  as  in  parallel  process¬ 
ing,  synchronization  is  handled  by  a  separate 
control  operation  as  described  below. 
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synch(d,x,y)  Synchronizing. 

The  operation  synch  provides  a  number  of 
equivalent  functions:  synchronization  of  parallel 
or  interleaved  processes,  mutual  exclusion,2 
and  indivisibility  of  operations.  The  argument  d 
must  be  a  data  structure.  The  argument  x  is  an 
expression  which  will  be  evaluated  only  if  no 
other  synch  with  d  as  its  first  argument  is  simul¬ 
taneously  evaluating  its  second  argument.  The 
argument  y  is  an  expression  which  will  be  evalu¬ 
ated  whenever  x  cannot  be  evaluated.  Thus,  if 
several  synch  operations  are  executed  simulta¬ 
neously  on  the  same  datum  d  then  exactly  one 
will  have  its  second  argument  evaluated  (which 
one  is,  however,  undetermined).  In  no  case  does 
the  synch  operation  cause  waiting  as  with  moni¬ 
tor. 

The  synch  operation  can  be  used  for  mutual 
exclusion  to  guarantee  that  only  one  process  at 
a  time  executes  a  critical  section  of  a  program 
or  modifies  a  datum.  Synch  also  provides  for  the 
relative  indivisibility  of  operations  because,  for 
all  synch  operations  on  a  given  datum,  the  evalu¬ 
ation  of  their  second  arguments  cannot  be  simul¬ 
taneous  or  interleaved  (i.e.,  they  are  indivisible 
with  respect  to  that  datum). 

cont(x)  Continuous  processing. 

One  control  path  will  be  called  continuous  with 
respect  to  another  control  path  if  and  only  if  all 
non-monitoring  operations  of  the  former  path  oc¬ 
cur  Detween  two  consecutive  steps  (i.e.,  state 
changes)  of  the  latter.  The  control  operation 
cont  causes  the  evaluation  of  its  argument  to  be 
continuous  with  respect  to  all  other  control  paths. 
If  two  cont  operations  are  executed  simultaneous¬ 
ly  then  the  evaluation  of  both  their  arguments 
would  be  continuous  with  respect  to  other  paral¬ 
lel  control  paths,  but  would  be  as  normal  con¬ 
trol  paths  with  respect  to  each  other  (e.g.,  synch 
would  be  required  for  mutual  exclusion).  Be¬ 
cause  continuous  and  parallel  processing  opera¬ 
tions  can  be  embedded  within  each  other  to 
arbitrary  depth,  many  levels  of  relative  continu¬ 
ity  can  occur.  These  roughly  approximate  the 
priority  levels  found  in  some  operating  systems. 
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return(v.p)  Call  and  return. 

The  previous  operations  can  be  combined 
using  functional  composition  to  define  new  con¬ 
trol  operations  (e.g.,  f).  Whenever  such  an  oper¬ 
ation  is  called  (e.g.,  f(x,,x2, . . . ))  then  the  actual 
parameters,  the  Xi’s,  are  associated  with  the  cor¬ 
responding  formal  parameter  names  and  control 
is  passed  to  the  expression  defining  f.  The  object 
which  describes  the  dynamic  state  of  the  evalu¬ 
ation  for  a  single  activation  of  an  operation  will 
be  called  a  process.  The  calling  operation  is  Im¬ 
plicit  in  the  use  of  functional  notation  and  need 
not  be  symbolized  separately. 

In  many  cases  control  is  to  be  returned  to  the 
calling  process  after  the  expression  defining  the 
operation  has  been  evaluated.  The  control  opera¬ 
tion  return(v.p)  causes  both  control  and  value  v 
to  be  returned  to  the  process  p  (usually  the 
caller). 

self()  and  callerQ 

The  operations  sell  and  caller  although  not 
control  operations  will  be  useful  in  describing 
other  operations.  The  value  of  sell  is  the  process 
in  which  it  is  executed.  The  value  of  caller  is  the 
process  which  called  the  current  process. 

quote(x)  and  eval(y,e) 

The  quote  operation  is  used  to  Inhibit  the  eval¬ 
uation  of  the  expression  x.  Eval  evaluates  the 
expression  y  in  the  context  of  environment  (i.e., 
process  e.  Thus  for  any  expression  x: 

x=  eval  (quote(x),self()). 


§ 

I 


1 


24 


I 


Examples  of  Control  Structure  Construction 

Consider  now  some  specific  control  structures 
which  can  be  built  from  the  preceding  primitives. 
One  commonly  used  control  is  the  coroutine.1 
A  coroutine  relation  between  two  processes  is 
similar  to  the  subroutine  in  that  the  initial  call 
builds  a  new  process  and  passes  control  to  that 
process.  The  coroutine  process,  however,  may 
pass  control  back  to  its  caller  before  reaching 
its  final  return.  Intermediate  coroutine  returns 
can  be  defined  as  follows: 

cocall(v,p)  =  return(v.p). 

Here  v  is  the  value  to  be  returned  and  p  is  the 
coprocess  (either  caller  or  called).  Notice  the 
symmetry  which  permits  each  of  the  coprocesses 
to  treat  the  other  as  if  it  were  a  subroutine  (i.e.. 
calling  the  process  with  the  routine  cocall  and 
receiving  the  return  value  via  the  return  in  the 
expression  defining  cocall. 

For  the  remaining  examples  additional  mne¬ 
monic  notation  will  be  used.  Infix  operators  will 
be  used  for  noncontrol  operations,  "x"  will  be 
used  for  cnioteW,  f[x,,x2, . . .]  will  be  used  for 
f(  x,  ,“x2", . . .),  'x  will  be  used  for  return 
(x, called)),  { c * x, ;  Cj-»x2;...}  will  be  used  for 
cond(  c,  ,"X|”,“C;",'‘x2", . . .),  and  x-e  will  be  used 
to  -eference  the  variable  whose  name  is  the  value 
of  x  in  the  context  of  the  environment  which  is 
the  value  of  e. 

Another  useful  control  structure  is  iteration. 
This  might  take  the  form  w/j//e(c,x,e)  where  the 
expression  x  is  repetitively  evaluated  as  long  as 
the  value  of  c  is  true  and  both  c  and  x  are  to  be 
evaluated  in  the  context  of  environment  e.  To  be 
more  precise,  while  (c,x,e)  first  evaluates  c  in  the 
context  of  e.  If  the  resulting  value  is  true,  then 
first  x  is  evaluated  in  the  context  of  e  and  second 
(i.e.,  after  the  evaluation  of  x  is  completed)  the 
while  operation  is  repeated.  If  an  evaluation  of  c 
does  not  yield  true  then  control  is  returned  to  the 
calling  process.  Note  the  similarity  between  the 
above  English  definition  of  while  (the  previous 
three  sentences)  and  the  formal  definition  as  a 
composition  of  primitive  control  operations  below: 
while(c,x,e)  =*  {eval(c.e)  -» seq(eval(x,e); 

while(c,x,e)] }. 


The  while  operation  can  be  used  to  define  more 
specialized  iterative  control  structures.  The  Al¬ 
gol-60  form  tor  l=A  step  B  until  C  do  S  has  sev¬ 
eral  interpretations  (4J.  A  liberal  interpretation  of 
the  Algol  report  [5]  would  allow  the  expressions, 
I,  A,  B.and  C  to  be  evaluated  only  once  giving  the 
following  definition 

for(l,A.B,C,S)  =  *  seq[l  called)  :=  A;  while("A-c* 

slgn(B)  g  0”, 

"seq[eval(S, caller());  I  called)  :=  A  :=  A-fB]”, 

self() )]. 

The  notation  I  called)  is  used  to  indicate  the 
(unique)  I  in  the  environment  of  the  caller  existent 
at  the  call. 

A  strict  interpretation,  however,  would  require 
that  all  the  arguments  be  evaluated  for  each  iter¬ 
ation  (in  fact  that  B  be  evaluated  twice  and  the 
address  of  I  evaluated  three  times)  as  follows: 

for(l,A,B,C,S)  =*  seq|eval(l,caller())’ called)  := 

eval  (A, called)): 

whilef'e  val(l, called)  (’called) 

-eval(C, called) )xsign(eval(B, called)))  S  0", 
"seq[eval(S, called)):  eval(l, called)  )caller()  :  = 
eval(l, called) )  •  called) +  eval(B, called) )”, 
self())]. 

The  Algol  condition  it  C  then  X  else  Y  can  be  de¬ 
fined  as: 

if(C,X,Y)  =*  {  C ->  eval(X, caller() ); 

true  -*  eval(Y, called)) }. 


A  more  unusual  control  structure  Is  the  side¬ 
track  control5  which  can  be  used  to  describe 
breadth  first  tree  search  algorithms  (e.g.,  recog¬ 
nizers  for  context-free  grammars).  The  operation 
sidetrack^, y)  causes  the  expressions  x  and  y  to 
be  evaluated  in  parallel.  The  expressions  repre¬ 
sent  alternative  branches  of  a  binary  search  tree. 
When  a  failure  condition  is  encountered  in  one 
of  these  branches  the  associated  control  path  will 
be  terminated  by  execution  of  the  operation  ter- 
minate().  If  a  branch  is  successful,  control  (and 
possibly  a  value)  will  be  returned  to  the  caller  of 
sidetrack.  Because  both  branches  might  be  suc¬ 
cessful  (e.g.,  an  ambiguous  string  in  the  case  of 
a  parser),  there  may  be  several  returns  of  control 
to  the  same  process.  To  prevent  the  resulting 
conflict  of  states,  all  returns  will  be  made  using 
the  multiple  parallel  return  operation  mpr  which 
returns  not  to  the  specified  process  but  to  a  copy 
of  it.  The  operations  sidetrack,  and  mpr  are  de¬ 
fined  below: 

sidetrack(x,y,p)  =  par[mpr(x,p);  mpr(y,p)] 
mpr(x,p)  =  return(eval(x,p),copv(p)) 

A  recognizer  R  for  terminal  strings  of  r  where 
r  ::=  A|B  r  could  be  written  as: 

R(string)  =  sidetrack(“{head(string)  =  'A'  -» 
tail(string);  true  -» terminate*)}”, 
“(head(string)=  ‘B'  R(tail(string) ) ;  true  -> 
terminated  }",self()) 
Understanding  of  control  is  in  its  infancy.  The 
above  has  attempted  to  isolate  and  solidify  some 
of  the  concepts  and  indicate  the  potential  for 
formal  means  for  defining  control.  Here  the  ap¬ 
proach  was  to  define  control  structures  as  com¬ 
positions  of  a  given  set  of  primitive  control  oper¬ 
ations.  The  choice  of  primitives  was  somewhat 
arbitrary  within  the  requirements  for  simplicity  of 
the  individual  primitives  and  that  they  span  one's 
intuitive  understanding  of  the  space  of  control 
structures.  Other  choices  could  have  been  made 
(in  fact,  a  slightly  modified  set  of  primitives  is 
being  implemented  to  satisfy  an  additional  re¬ 
quirement:  run  time  efficiency  on  existing  hard¬ 
ware).  Finally,  a  few  examples  have  been  givon 
to  illustrate  some  of  the  variety  in  control  struc¬ 
tures  and  to  demonstrate  control  definition  by 
composition  of  the  proposed  primitives.  Addi¬ 
tional  examples  ore  given  in  reference  3. 
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Bliss: 

A  Language  for  Programming  Systems 

William  A.  Wulf 

The  development  of  sophisticated  programming 
systems,  notably  programming  languages  and 
operating  systems,  has  largely  been  responsible 
for  the  increasingly  wide  application  of  com¬ 
puters.  The  primary  objective  of  these  systems 
is  to  permit  the  solution  of  a  problem  to  be  stated 
more  concisely,  and  in  terms  more  natural  to 
the  problem,  than  is  possible  with  the  numeric 
instruction  encoding  interpreted  by  computer 
hardware.  This  paper  deals  with  a  programming 
system,  specifically  a  programming  language, 
which  is  designed  primarily  for  writing  other  pro¬ 
gramming  systems. 

It  is  curious,  but  true,  that  although  great 
strides  have  been  made  in  creating  programming 
systems  to  support  the  programming  activities  of 
application  areas,  systems  programmers  them¬ 
selves  have  been  the  beneficiary  of  almost  none 
of  this  progress.  In  particular,  the  vast  majority 
of  programming  systems  continue  to  be  written 
in  assembly  language — scarcely  one  step  re¬ 
moved  from  the  hardware  numeric  encodings. 
Why?  Why  haven’t  systems  programmers  chosen 
to  write  their  systems  using  existing  programming 
systems,  particularly  a  programming  language, 
and  why  hasn’t  their  management  insisted  upon 
it?  The  advantage  of  using  a  so-called  “higher- 
level”  language  are  well  known  and  thoroughly 
documented:  programmers  are  most  productive, 
programs  contain  fewer  errors  and  are  more 
easily  repaired,  programs  are  more  easily  under¬ 
stood  and  modified,  etc. 


Part  of  the  reason  why  systems  programmers 
continue  to  use  archaic  tools  is  simply  inertia — 
it’s  always  been  done  that  way.  A  more  signifi¬ 
cant  reason,  however,  is  the  feeling  on  the  part 
of  practicing  systems  programmers  that  existing 
programming  languages  are  not  appropriate  for 
the  kind  of  work  that  they  do.  In  this  context  the 
question  of  why  systems  programmers  don’t  use 
a  higher-level  language  becomes:  "What  about 
systems  programming  is  different  from  other  pro¬ 
gramming  tasks,  and  how  should  these  differ¬ 
ences  manifest  themselves  in  a  programming 
language  specifically  designed  for  this  applica¬ 
tion?” 

In  many  ways  systems  programming  is  like 
other  programming  applications.  Thus,  for  ex¬ 
ample,  algorithms  used  in  the  construction  of 
assemblers,  compilers,  interpreters,  operating 
systems,  etc.,  are  certainly  different  from  those 
which  control  missile  trajectories,  simulate  the 
behavior  of  a  nuclear  reactor  core,  or  produce  a 
corporate  payroll.  But  many  of  the  issues  which 
arise  in  the  implementation  of  these  algorithms 
are  similar.  Issues  such  as  the  order  in  which 
numeric  computations  are  performed  in  order  to 
maintain  accuracy  are  as  important  in  a  com¬ 
piler's  number  conversion  routines  as  in  reactor 
simulations;  proper  overlapping  of  input-output 
with  computation  is  critical  to  systems  programs 
as  well  as  to  payroll  programs;  etc.  There  are 
differences  in  emphasis  between  these  applica¬ 
tions,  however,  Which  give  rise  to  differences  in 
language  features.  Some  of  the  more  Important 
differences  for  systems  programs  are: 

—  efficiency 

—  access  to  all  hardware  features 

—  minimal  run-time  support 

—  evolution  of  the  resultant  system. 
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Ideally  all  programs  would  be  maximally  effi¬ 
cient-rapid  in  execution  and  conservative  in  their 
use  of  storage.  In_  many  applications,  however 
economy  in  programming  effort  and  conciseness 
in  expression  are  traded  for  execution  speed  and 
use  of  storage.  No  programmer  deliberately 
writes  a  program  to  be  slow  or  wasteful  of  stor¬ 
age;  however,  due  to  the  high  frequency  of  the 
use  of  systems  programs  the  emphasis  on  effi¬ 
ciency  is  generally  greater  than  in  other  applica¬ 
tions.  * 

Most  programming  systems  hide  from  their 
user,  for  his  own  protection  and  convenience, 
idiosyncracies  of  particular  hardware  machines. 
To  the  system  programmer,  however,  these  idio¬ 
syncracies  are  an  integral  part  of  the  problem 
and  must  not  be  hidden. 

Many  features  of  modern  programming  sys¬ 
tems  are  not  available  directly  in  the  hardware 
on  which  they  run.  Instead,  these  features  are 
implemented  with  software  "run-time  support” 
programs— of  whose  existence  the  user  need 
not  be  consciously  aware.  A  simple  example  is 
the  trigonometric  "sine"  function  in  most  scien¬ 
tific  programming  languages.  Few  computers 
have  this  function  in  hardware — rather  it  is  eval¬ 
uated  by  a  subprogram  automatically  included 
in  the  users  program  by  the  programming  system 
without  any  overt  action  on  the  user’s  part.  The 
systems  programmer,  whose  task  it  is  to  create 
such  support,  cannot  in  turn  require  it.  The  sys¬ 
tems  programmer  must  be  able  to  create  and 
exploit  his  own  support,  thus  "bootstrapping”  to 
increasingly  sophisticated  systems. 


A  final  observation  on  programming  systems 
is,  perhaps,  the  most  important  of  all.  Program¬ 
ming  systems  are  never  finished  but  are  in  a 
constant  state  of  evolution.  New  features  are 
constantly  added  and  old  errors  repaired.  The 
more  heavily  a  system  is  used,  the  more  rapid  the 
rate  of  evolution  and  repair.  This  situation  seems 
inevitable  so  long  as  new  application  areas,  all 
with  slightly  differing  requirements,  continue  to 
emerge. 

A  central  problem  of  devising  a  language  for 
systems  programming  would  appear  to  be  that  of 
providing  mechanisms  for  enabling  the  program¬ 
mer  to  cope  with  this  evolution  (of  programs 
written  in  the  language)  while  satisfying  the  other 
three  criteria  mentioned  earlier:  efficiency,  ac¬ 
cess  to  the  hardware,  and  minimal  run-time 
support. 

The  present  state  in  programming  systems  rel¬ 
ative  to  coping  with  evolution  is  summed  up  in 
the  programming  jargon  word:  "kludge”. 

I  just  had  a  neat  idea  for  a  new  feature. 
Now,  the  system  wasn’t  meant  to  do  this, 
but  ...  it  \  contort  this  a  little,  ar.d  rebuild 
that,  and  since  no  one  uses  these  bits 
Gee,  I  think  it’ll  work.” 

That's  a  kludge  with  a  small  "k”.  Now,  repeat 
the  process  fifty,  or  a  hundred,  or  a  thousand 
times  by  many  different  people  at  computer  in¬ 
stallations  scattered  across  the  country  and  the 
system  becomes  a  Kludge.  Unfortunately  almost 
all  existing  systems  are  Kludges,  The  properiv 
of  systems  which  results  in  their  evolution  toward 
Kludges,  and  which  a  systems  programming  lan¬ 
guage  must  correct,  is  the  ease  in  making  trivial 
changes  and  the  difficulty  in  making  fundamental 
changes  to  systems.  The  consequences  of  this 
property  is  the  introduction  of  peripheral  modifi¬ 
cations  which  subvert  and  distort  the  original 
structure  of  the  system  and  lead  ultimately  to 
inefficient,  "dirty”  systems. 

The  remar  Jer  of  this  paper  is  devoted  to  the 
description  of  a  language,  Bliss,  which  is  de¬ 
signed  to  satisfy  the  goals  set  out  above  for  a 
systems  programming  language. 
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The  Representation  of  Data  Structures: 

A  Thesis 

The  surface  structure  of  the  Bliss  programming 
language  is  a  logical,  but  not  especially  innova¬ 
tive,  evolution  from  the  Algol-60  family  of  lan¬ 
guages.  There  is  a  central  aspect  of  the  language, 
however,  which  distinguishes  it  from  other  mem¬ 
bers  of  this  family,  that  of  the  representation  of 
data  structures.  That  role  of  representation  fol¬ 
lows  from  the  thesis  that:  "The  central  issue  in 
systems  programming  is  that  of  the  representa¬ 
tion  of  data  structures.  This  issue  is  the  key  to 
both  efficiency  and  to  the  rational  evolution  of 
programming  systems."  Subsequent  sections  will 
deal  with  the  structure  of  the  Bliss  language  and 
in  particular  with  the  manifestation  of  the  concern 
with  representation  expressed  by  the  thesis.  In 
this  section  we  are  concerned  only  with  the 
meaning  and  implications  of  the  thesis. 

All  programming  deals  with  structured  infor¬ 
mation — that  is,  with  atomic  information  items 
which  not  only  have  a  value,  but  also  bear  some 
relation  to  other  atomic  information  items.  These 
relationships  are  expressed  in  programming  lan¬ 
guages  by  "data  structures"  (such  as  arrays, 
lists,  queues,  stacks,  etc.)  which  are  used  to 
model  the  real  relations  wh'ch  exist  between 
data  items.  Most  programming  languages  con¬ 
tain  a  fixed  et  of  such  data  structures;  namely, 
those  deemed  appropriate  to  an  application  area 
by  the  designers  of  the  language.  Scientific  lan¬ 
guages  such  as  Algol  and  Fortran,  for  example, 
contain  only  arrays  (as  models  of  the  mathemati¬ 
cal  vector  and  matrix  structures)  while  string 
processing  languages  such  as  SNOBOL  contain 
sequences  of  characters  as  intrinsic  structures. 
These  data  structures  are,  in  turn,  represented, 
or  modeled,  by  the  implementor  of  the  program¬ 
ming  system  in  terms  of  the  explicit  data  struc¬ 
tures  of  a  hardware  computer. 


So  long  as  the  data  structures  required  by  an 
application  area  are  small  in  number  and  fairly 
uniform  over  the  area,  as  is  largely  the  case  in 
scientific  applications,  this  situation  is  accept¬ 
able.  In  systems  programming,  however,  this  is 
decidedly  not  the  case.  All  of  the  structures 
mentioned  above  are  used,  as  well  as  many 
others  that  have  no  generic  name.  Furthermore, 
in  the  interest  of  efficiency,  many  different  repre¬ 
sentations  of  the  same  logical  structure  are  used. 
To  achieve  reasonable  efficiency  it  is  imperative 
that  a  language  to  be  used  for  systems  program¬ 
ming  permit  the  definition  of  the  representations 
to  be  used. 

When  a  programming  system  is  initially  built, 
the  conscientious  systems  programmer  devises 
representations  to  maximize  the  efficiency  of  his 
system.  As  new  features  are  added  to  a  system 
and  it  evolves,  the  original  representations  may 
no  longer  be  the  most  appropriate.  To  the  extent 
to  which  new,  more  natural  representations  can¬ 
not  be  provided,  the  original  representations  will 
be  modified,  thus  circumventing  the  reorganiza¬ 
tion  that  evolution  requires,  ergo  a  kludge. 

In  order  to  achieve  the  criteria  outlined  above, 
two  principles  were  followed  in  the  design  of  the 
data  structure  facility  of  Bliss: 

—  The  user  must  be  able  to  specify  the  ac¬ 
cessing  algorithm  for  elements  of  a  struc¬ 
ture  (which  is  equivalent  to  specifying  the 
representation)  at  as  low  a  level  as  he 
deems  necessary. 

—  The  structure  definition  and  the  algorithms 
which  operate  on  the  elements  of  a  struc¬ 
ture  must  be  separated  in  such  a  way  that 
either  can  be  modified  without  affecting 
the  other. 
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lanL!Lpf!°mary  ?  conventional  Programming 
anguages  to  include  a  number  of  implicit  data 

ZT'eS  (KK*  “  a"ays'  lis,s'  s,^"gs.  and  s'o 
forth)  as  an  integral  part  of  the  language  The 

ZP  TeT  01  ,tee  lan^9«  chooses  a^epre- 
sentalron  lor  these  structures  and  the  languages 

tirpIv^d  ffH0  C^tr01  °Ver  ,hem’  B,iss  ,akes  an  en¬ 
tirely  different  approach.  The  first  of  these  prin- 

c-pies  reflects  the  need  for  flexibility  and  effi¬ 
ciency  ,n  systems  programming.  I,  also  reflects 
he  conviction  that  the  designer  of  Bliss,  cannot— 

svstemUn  n0t“PrediCt  whi<*  representations  a 
system  progiammer  will  need.  Any  given  set  of 

primitive  structures,  with  or  without  the  ability  to 
define  more  complex  structures  from  them  wou  d 
be  totally  inappropriate.  Instead,  representations 
of  structures  are  defined  in  Bliss  in  terms  of  the 
computational  procedure  (the  algorithm)  by  which 
elements  of  that  structure  are  accessed.  Thus 
no  decisions  are  made  a  priori  by  the  Biiss  im¬ 
plementation  concerning  the  most  appropriate 

lures8' “and'Thu0'  “"'s'"’  mosl  6lemenl«>'  «mc- 
choosing  one  maXl,nal  "“'““V 

The  second  principle  reflects  a  concern  for  the 
modification  of  systems  written  in  Bliss.  So  lonq 

frnm  fhrep,rese?ua,i0n  ° '  s,ruc,ures  is  separated 
tain'prihe  a,pon  hms  wh,ch  operate  on  data  con- 
amed  in  those  structures,  and  the  representa- 
tions  are  easily  modifiable,  it  is  possible  for  sys¬ 
tems  to  evolve  in  an  orderly  fashion.  Of  course 

SwS  bp9,,5"?- VnCil,,y  d°eS  n°'  9uarantee  ‘bat’ 
wH  be  used  mtell,gently_but  that  is  an  educa- 

\ztT0r,b'y  mana9eriai’ issue  and  «*  a 

nthMos,,ris‘ing  'anguages  satisfy  one  or  the 
other  of  the  above  criteria  but  not  both.  Assembly 
languages  allow  (indeed,  demand)  algorithmic 
specification  of  data  structures  since  they  have 

'mp  ,C!  d^'a  s,ruc,ures  0,her  'ban  those  repre¬ 
sentable  m  the  hardware  itself.  The  specification 

,  KrVn  3n  assemblV  language  program 
a  f  localized'  however,  and  is  usually 
J  buted  ,0  al1  P|aces  where  an  element  of  the 

modifv^Ai5  aCC®SSed'  ,hus  makin g  it  difficult  to 
modify.  Algol,  Fortran,  etc.,  on  the  other  hand 

localize  the  specification  of  a  structure  to  the 
place  where  it  is  declared  but  do  not  allow  its 
representation  to  be  defined  by  the  programmer 


Description  of  Bliss 

*ivel'inS»ITpay  be  Cf!araC,eriZed  38  an  Al9°'  deriva- 
t'V® th<V sense  that  "  has  a  similar  expression 
to  mat  and  operator  hierarchy,  a  block  structure 
with  lexically  and  dynamically  local  variables 
s.m'lar  conditional  and  interative  constructions' 
and  (potentially)  recursive  procedures.  The  simi- 
lanty  stops  shortly  beyond  this  surface  compari¬ 
son,  however.  Bliss  will  be  described  in  terms  of 
"S  asPects:  (1)  the  underlying  storage  con- 
nlpPtp  !f  fC°,n,ro1'  and  (3)  da,a  s'ructures.  A  com- 

tPhP  Rr^D  'fH  °f  ,he  lan9ua9e  may  be  found  in 
the  Bliss  Reference  Manual.1 

1.  Storage  Names  and  Identifiers 

In  order  to  implement  the  objectives  set  out 
previously  concerning  the  representation  of  data 
structures  it  is  first  necessary  to  adopt  precise 

"iriPnC.°fnS,S'  ^  m,erpre,a,ions  of  the  concepts  of 

hplwn'  l6th'  name  '  3nd  'Value"’  The  distinction 
between  these  concepts  is  at  best  fuzzy  in  most 

programming  languages.  The  distinction  to  be 

St 18  f  b6tWeen  an  0bjecl'  a  name  'or  'he 
object,  and  a  name  of  the  name,  in  English  prose 

lZ,Z  rS  la'k  ab°Ul  lhS  Smallesl  i^eger 

larger  than  five,  one  writes:  M 

6 

The  above  mark  serves  as  a  name  for  that  par- 
inslanue"'699''  bU'  'he'e  many  olhers- 
..  ,,  Slx  mj  i  vi  5+1 

Now,  ,f  one  wishes  to  talk  about  one  of  these 

PesC,f,C,nameS  °f  SiX'  °ne  encloses  "  in  quotes; 

„r  h.6  aerves  as  ‘be  name  of  a  particular 

which' in  ,um' namas  a  ^ 


tarns 3£ 


sum 


bsssmti 


Bliss  makes  a  similar  distinction  except  that 
the  objects  named  are  variables,  i.e.,  their  value 
may  change  in  time,  and  are  represented  by  some 
storage  media  in  the  computer,  The  name  of  a 
variable,  also  called  a  pointer  to  the  variable  is 
encoded  as  a  bit  pattern  which  itself  may  be 
manipulated  and  in  particular  may  be  the  value 
of  another  named  object.  An  identifier  serves  as 
the  name  of  a  name  of  (pointer  to)  a  variable, 
To  complete  our  analogy,  then,  a  Bliss  identifier 
serves  the  role  of  the  quoting  device  in  English, 
pointers  correspond  to  simple  names,  and  the 
objects  ultimately  named  are  variables  repre¬ 
sented  in  storage.  The  weakness  in  this  analogy 
is  that  English  provides  few  mechanisms  for  per¬ 
forming  operations  on  names  while  in  Bliss  names 
are  encoded  as  bit  patterns  and  hence  may  be 
operated  upon  by  any  operator  in  the  language 
(see  below). 

A  Bliss  program  operates  with  and  on  a  num¬ 
ber  of  storage  segments.  A  storage  segment  con¬ 
sists  of  a  fixed  and  finite  number  of  words,  each 
of  which  is  composed  of  a  fixed  and  finite  num¬ 
ber  of  bits.  A  contiguous  set  of  bits  within  a  word 
is  called  a  field.  A  field  may  be  named,  the  value 
of  a  name  is  also  called  a  pointer  to  the  field.  In 
particular,  an  entire  word  is  a  field  and  may  be 
named. 

In  practice  a  segment  generally  contains  either 
program  or  data,  and  if  the  latter,  it  generally  is 
an  integer  number,  a  floating  point  number,  char¬ 
acters),  or  a  pointer  to  other  data.  To  a  Bliss 
program,  however,  a  field  merely  contains  a  pat¬ 
tern  of  bits  on  which  the  programmer  may  place 
any  interpretation  he  chooses.  Various  specific 
operations  are  defined  in  Bliss  and  may  be  ap¬ 
plied  to  fields  and  bit  patterns,  such  as:  fetching 
a  bit  patterns  (value)  from  a  field,  storing  a  bit 
pattern  into  a  field,  arithmetic,  comparison,  and 
boolean  operations  on  bit  patterns,  and  so  on. 
These  operations  are  roughly  those  provided  by 
the  hardware.  From  these  all  other  programmer- 
defined  operations  must  be  built.  The  interpre¬ 
tation  placed  upon  a  bit  pattern  and  consequent 
transformation  performed  by  an  operator  is  an 
intrinsic  property  of  the  operator,  and  not  of  its 
operands.  In  particular,  names  (pointers)  are  bit 
patterns  and  as  such  are  manipulable  objects  In 
the  language. 


Segments  and  identifiers  are  introduced  into  a 
Bliss  program  by  declarations,  called  'allocation 
declarations’;  for  example: 

global  g; 
own  x,y[5],  z; 
local  p[100j; 

Each  declaration  introduces  one  or  more  seg¬ 
ments  and  binds  the  identifiers  mentioned  to  the 
name  of  the  first  word  of  the  associated  segment. 

The  segments  introduced  by  declarations  con¬ 
tain  one  or  more  words;  the  size  of  a  segment 
may  be  specified  (as  in  “local  p[100]”)  or  de- 
fauted  to  one  (as  in  “global  g;”).  The  identifiers 
introduced  by  a  declaration  are  lexically  local  to 
the  block  in  which  the  declaration  is  made  (that 
is,  they  obey  the  usual  Algol  scope  rules)  with 
one  exception — namely,  global  identifiers  are 
available  to  other,  separately  compiled  programs. 
Segments  created  by  own  and  global  declarations 
are  created  only  once  and  are  preserved  for  the 
duration  of  the  execution  of  a  program.  Seg¬ 
ments  created  by  local  declarations  are  created 
at  the  time  of  block  entry  and  are  preserved  only 
for  the  duration  of  the  execution  of  that  block. 
Reentry  of  a  block  before  it  is  exited  (by  recursive 
function  calls,  for  example)  behaves  such  that 
local  segments  are  dynamically  local  to  each  in¬ 
carnation  of  the  block. 
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It  is  important  to  reiterate  that  identifiers  are 
bound  to  names  by  declarations,  and  that  a  name 
is  a  pointer  (a  particular  interpretation  on  a  bit 
pattern).  Thus,  the  value  of  an  instance  of  an 
identifier,  say  x,  is  a  name  of,  or  pointer  to,  x, 
not  the  value  of  the  field  named  by  x.  Moreover, 
operators  may  be  applied  to  names  to  yield  new 
names.  This  interpretation  requires  a  “contents 
of"  or  "value  of"  operator  for  which  the  symbol 
has  been  chosen.  The  operator  may  be 
applied  to  any  expression — thus  placing  a  "point¬ 
er"  interpretation  on  the  bit  pattern  which  results 
from  evaluating  that  expression.  Thus  the  va'ue 
of  the  expression  “X”  is  the  name  (a  pointer)  c! 
a  specific  variable,  X,  ".X"  is  the  bit  pattern 
stored  in  X  and  ",  .X”  is  the  value  of  a  variable 
whose  name  is  stored  in  X.  If  we  denote  the  bit 
pattern  which,  when  interpreted  as  a  pointer, 
names  X  by  X'  and  use  boxes  to  represent  storage 
cells,  then  the  situation  described  above  is: 

X  X  (^X') 
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There  are  two  additional  declarations  whose 
effect  is  to  bind  identifiers  to  values  (possibly 
names),  but  which  do  not  create  segments;  ex¬ 
amples  are: 

external  s; 

bind  y2  =  y-)-2,  pa  =  p-t-.a; 

An  external  declaration  binds  one  or  more 
identifiers  to  the  names  represented  by  the  same 
identifier  declared  global  in  another  program. 
The  bind  declaration  binds  one  or  more  identi¬ 
fiers  to  the  value  of  an  expression  at  block  entry. 
Potentially  the  value  of  th!s  expression  may  not 
be  calculable  until  run-time,  e.g.,  as  in  "pa  = 
p+.a"  above. 


2.  Operations  and  Control 

Bliss  is  an  expression  language;  that  is,  every 
executable  construct,  including  those  which  man¬ 
ifest  control,  is  an  expression  and  computes  a 
value.  There  are  no  statements  in  the  sense  of 
Algol  or  PL/I.  Expressions  may  be  concatenated 
with  semicolons  to  form  compound  expressions, 
where  the  value  of  a  compound  expression  is 
that  of  its  last  (rightmost)  component  expression. 
Thus  may  be  thought  of  as  a  dyadic  operator 
whose  value  is  simply  that  of  its  righthand 
operand.  A  pair  of  symbols  begin  and  end,  or 
left  and  right  parentheses,  may  be  used  to  em¬ 
brace  such  a  compound  expression  and  convert 
it  into  a  simple  expression.  A  block  is  merely  a 
special  case  of  this  construction  which  happens 
to  contain  declarations;  thus  the  value  of  a  block 
is  defined  to  be  the  value  of  its  constituent  ex¬ 
pression. 

The  assignment  operation,  is  a  dyadic 

operator  whose  left  operand  is  interpreted  as  a 
pointer  and  whose  right  operand  is  an  uninter¬ 
preted  bit  pattern.  The  right  operand  is  stored 
into  the  field  named  by  the  left  operand;  the  value 
of  the  expression  is  that  of  its  right  operand. 
Recalling  the  interpretation  of  identifiers  and  the 
operator,  the  expression 
x  «-  .x  +  1 

causes  the  value  of  the  field  named  by  x  to  be 
incremented  by  one.  The  value  of  the  entire  as¬ 
signment  expression  is  that  of  the  incremented 
value. 

There  are  five  forms  of  explicit  control  expres¬ 
sion:  conditional,  loop,  case-select,  function,  and 
escape. 

The  conditional  expression 

if  £  ,  then  £  j  else  £ , 

is  defined  to  have  the  value  of  the  expression  £? 
just  in  the  case  that  the  rightmost  bit  of  expres¬ 
sion  £  is  a  1;  it  has  the  value  of  £,  otherwise. 
The  abbreviated  form  "it  £,  then  £/’  is  con¬ 
sidered  to  be  identical  to  "it  £,  then  £?  else  0”. 
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Whereas  the  conditional  expression  provides 
two-way  branching,  the  case*  and  select'  ex¬ 
pression  provide  more  general  n-way  branching: 
case  e  of  set  £0;  £,;...;  £„tes 
select  e  of  nset  £  2: 

€  2n'  €  ?n.i  tesn 

The  value  of  a  case  expression  is  £0;  that  is,  the 
expression  e  is  evaluated  and  this  value  is  used 
as  an  index  to  select  one  of  the  expressions 
<Ei  (0  —  i  S  n),  which  then  becomes  the  value 
of  the  entire  case  expression. 

The  select  expression  is  somewhat  similar  to 
the  case  expression  except  that  the  expression 
e  is  not  used  as  a  simple  index,  and  hence  not 
restricted  to  the  range  0  <  e  <  n.  Instead, 
after  e  has  been  evaluated  its  value  is  succes¬ 
sively  compared  with  the  first  element  of  each 
of  the  pairs  £2i:£2(,.p  in  the  order  of  increasing 
values  of  i.  For  each  pair  such  that  e  =  £?i  the 
the  second  element  of  the  pair,  £2i„,  is  also 
executed  and  the  last  of  these  to  be  executed 
defines  the  value  of  the  entire  select  expression. 

Loop  expressions  imply  repeated  execution 
(possibly  zero  times)  of  an  expression  until  a 
specific  condition  is  satisfied.  There  are  several 
forms,  of  which  we  shall  mention  three: 
while  £,  do  £ 
do  £  while 

incr  <  id  >  from  £,  to  £ ,  by  £  3  do  £ 


‘The  symbol  pairs  set-tes  and  nset -tesn  are  some¬ 
what  arbitrarily  chosen  bracketing  devices  which 
delimit  the  set  of  choices  In  case  and  select  expres¬ 
sions. 


In  the  first  form  the  expression  £  is  repeated  so 
long  as  the  rightmost  bit  of  £ ,  remains  1.  The 
second  form  is  similar  except  that  £  is  evaluated 
before  £  „  thus  guaranteeing  at  least  one  execu¬ 
tion  of  £.  The  last  form  is  similar  to  the  familiar 
"step  . . .  until"  construct  of  Algol,  except  (1)  the 
control  variable,  <id>,  is  local  to  £,  and  (2) 
€i,€2  and  £,  are  computed  only  once  (before 
entry  to  the  loop).  Except  for  the  possibility  of 
an  escape  expression  within  £  (see  below)  the 
value  of  a  loop  expression  is  uniformly  taken 
to  be  -1. 


Invocation  of  functions  (subroutines)  is  speci¬ 
fied  by  the  usual  notation: 


€  (  €  H  €  2  •  •  •  £n) 

This  expression  causes  activation  of  the  segment 

named  by  £  passing  the  values  £ .  £n  as 

parameters.  The  value  of  a  function  call  is  that 
resulting  from  execution  of  the  body  of  the  named 
function. 

The  familiar  "goto . . .  label”  form  of  control 
has  not  been  included  in  Bliss.  Unrestricted 
goto’s  require  considerable  run-time  support 
(principally  due  to  the  possibility  of  jumping  out 
of  functions  and/or  blocks).  More  importantly, 
the  use  of  the  general  goto,  because  of  the 
implied  violation  of  program  structure,  is  a  major 
villain  in  making  programs  difficult  to  understand, 
modify  and  debug.  The  control  mechanisms  al¬ 
ready  mentioned  provide  most  of  the  control 
needed.  In  addition  a  highly  structured  form  of 
forward  branch,  the  escape-expression,  has  been 
included.  There  are  eight  forms  of  escape;  one 
for  each  control  environment: 

exitblock  £  exitcase  £ 

exitcompound  £  exitselect  £ 

exitloop  £  exit  £ 

exitset  £  return  £ 

Each  escape  expression  causes  control  to  exit 
from  a  specified  control  environment  (a  block,  a 
loop,  or  a  case  expression,  for  example)  and 


defines  a  value  (£)  for  it  (exit  exits  from  any 
control  environment;  return  exits  from  a  function). 

Other  control  expressions  are  defined  in  the 
language  but  will  not  be  discussed  here. 
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3.  Data  Structures 

In  order  to  satisfy  the  objectives  sot  out  earlier 
concerning  the  representation  of  data  structures, 
no  implicit  structures  are  included  in  Bliss.  In¬ 
stead,  mechanisms  are  provided  for  defining  rep¬ 
resentations  algorithmically  (that  is,  specifying 
the  access  method  for  elements  of  the  structure), 
for  associating  particular  representations  with 
particular  identifiers,  and  for  invoking  the  access 
algorithm  associated  with  an  identifier.  The  defi¬ 
nition  of  a  representation  scheme  is  made  by  a 
declaration  of  the  form 

structure  <scid>[<formal  parameter  list  >]  =  £ 
The  <scid>  in  this  declaration,  calied  a  struc¬ 
ture  class  identifier,  may  then  be  used  to  asso¬ 
ciate  the  accessing  algorithm,  denoted  £  above, 
with  specific  identifiers  by  another  declaration 
map  <scid>  <idchuck> 

(where  an  <idchuk>  is  a  sequence  of  identifiers, 
<id>'s,  separated  by  colons)  each  of  which  is 
to  be  associated  with  <scid>.  Once  the  asso¬ 
ciation  between  a  variable  identifier  and  a  struc¬ 
ture  representation  has  been  established,  the 
name-form  "<id>[  £,,  £2 . £„]"  becomes  val¬ 

id,  and  denotes  invocation  of  the  access  algorithm 
defined  in  the  associated  structure  declaration 
(with  an  appropriate  substitution  of  actual  for 
formal  parameters).  Thus  the  syntactic  device 
‘'<id>(  £ ,,  £2, . . .  £„]”  denotes  a  name  (a  point¬ 
er)  resulting  from  the  evaluation  of  a  user-de¬ 
fined  expression. 


Consider  the  following  example: 
begin 

structure  array2[i,j]  =  (.array2+ .i*10+ .j); 
own  x  [100],y  [100]  ,z[1 00] ; 
map  array2  x:y:z; 

x[.a,.b]  <-  .y[.b,.a]; 


end; 

In  this  example  a  very  simple  structure  represen¬ 
tation,  array2,  for  two  dimensional  (10+10)  arrays, 
is  introduced.  The  structure  is  to  be  represented 
by  storing  rows,  and  row  elements,  in  contiguous 
memory  locations;  we  declare  three  segments 
with  names  "x”,  “y”,  and  "z”  bound  to  them;  and 
the  structure  class  "array2"  is  associated  with 
these  names.  The  syntactic  forms  "x(£,,  £2]" 
and  ‘‘y[£3,  £«]"  are  valid  within  this  block  and 
denote  names  resulting  from  evaluation  of  the 
accessing  algorithm  defined  by  the  array2-sfruc- 
ture  declaration  (with  an  appropriate  substitution 
of  actual  for  formal  parameters). 


For  purposes  of  exposition  (though  it’s  not  im¬ 
plemented  this  way)  one  may  think  of  the  struc¬ 
ture  declaration  as  defining  a  function  which 
takes  both  the  name  of  an  instance  of  a  structure 
and  its  accessing  parameters  as  arguments  The 
structure  declaration  in  the  previous  example, 
structure  array2[i,j]  =  (.array2+.i*10+.j); 
is  conceptually  identical  to  a  function  declaration 
function  array2(f0,fl,f2)  =  (.f0+.fl*10+.f2)- 
The  expression  ‘‘x[.a,.b]"  and  ”y[.b,.a]”  corre¬ 
spond  to  calls  on  this  function,  i.e.,  to  “arrav2 
(x,.a,.b)”  and  ‘,array2(y,.b,.a),’.  V 

Consider  how  the  combined  mechanisms  of  the 
structure  declaration,  map  declaration,  and  name 

orm  ‘‘<id>[, .,)"  achieve  the  objectives  earlier 
set  for  them. 

First,  the  programmer  has  complete  control 
over  the  representational  scheme  for  each  of  his 
data  structures.  Since  names  are  manipulable 
objects  in  the  language,  any  computation  which 
is  possible  in  the  machine  can  be  used  to  pro¬ 
duce  a  name,  and  hence  can  be  used  as  the 
access  algorithm  for  elements  of  a  structure 
Specific  properties  of  specific  instances  of  a 
data  structure,  the  size  of  its  elements,  the  usual 
form  of  their  access,  etc.,  may  be  fully  exploited. 

Second,  the  specification  of  a  representation 
and  the  algorithms  which  manipulate  elements  in 
the  structure  have  been  separated.  The  syntactic 
form  “X[.i,3J”  denotes  the  name  of  a  specific 
element  of  the  structure  called  X,  independent  of 
how  that  structure  is  represented;  the  represen¬ 
tation  of  that  structure  may  be  changed  by  alter¬ 
ing  the  structure  declaration  without  changing 
the  algorithms  which  operate  on  elements  of  the 
structure. 


Efficiency 

Although  it  has  not  been  explicitly  discussed 
in  the  preceding  material,  a  major  aspect  of  the 
Bliss  effort  has  been  to  design  the  language  in 
such  a  way  that  it  is  possible  for  the  Bliss  com¬ 
piler  to  produce  highly  efficient  object  programs 

comparable  to  those  which  a  good  program¬ 
mer  would  write  in  assembly  language.  There 
are  two  facets  to  this  aspect  of  the  language 
design.  First,  the  language  had  to  provide  nat¬ 
ural  mechanisms  through  which  the  user  can  gain 
access  to  the  underlying  hardware.  In  a  few 
cases  this  means  including  specific  ianguage 
constructs  which  utilize  specific  hardware,  fea¬ 
tures;  in  most  cases,  however,  it  means  choosinq 
he  overall  structure  of  the  language  so  as  to 
mesh  neatly  with  the  underlying  hardware  struc¬ 
ture^  Second,  the  language  had  to  be  designed 
such  that  its  compiler  could  reasonably  interpret 
the  programmer’s  intentions  and  produce  "opti¬ 
mal  code.  This  aspect  of  the  Bliss  design  is  its 
most  easily  documentable  success;  examples  of 
numeric  subroutines,  for  example,  written  in  Bliss 
generate  one-half  to  one-third  the  code  produced 
by  some  of  the  most  highly  touted  optimizing 
compilers  (e.g.,  IBM/360  Fortran  H) 
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Experiences  Using  Bliss 

The  Bliss  language  has  been  in  active  use  for 
approximately  two  years  for  a  wide  variety  of 
systems,  including:  the  Bliss  compiler  itself,  a 
WATFOR-like  fast  Fortran  compiler,  an  implemen¬ 
tation  of  APL  (a  conversational  programming  sys¬ 
tem),  a  SIMULA-like  discrete  event  simulation 
system,  an  i/o  support  system,  an  accounting 
system,  the  kernel  of  a  small  operating  system, 
and  many  applications  programs.  Our  experience 
using  the  language  over  the  past  ;wo  years,  and 
in  watching  others  use  it  on  a  variety  of  systems, 
gives  us  some  contidence  that  we  can  objectively 
evaluate  it  as  a  tool  for  systems  programming. 
For  example,  along  the  dimension  of  programmer 
productivity  (measured  in  instructions/program¬ 
mer/  day  (i/p/d)  of  debugged  code)  we  recently 
obtained  the  following  data  on  some  projects 
at  CMU: 


Man- 


Project 

Language 

Size 

months 

i/p/d 

Algol 

Assembly  Lang. 

12k 

50 

11 

Bliss 

Bliss 

31k 

62 

23 

APL 

Bliss 

30k 

35 

39 

TENFOR* 

Bliss 

12k 

7 

78 

BLIOb 

Bliss 

7k 

2 

159 

POOMASc 

Bliss 

7k 

3 

100 

TECH* 

Bliss 

3k 

1  Vz 

91 

■’  the  WATFOR-like  fast  Fortran  compiler 
b  the  i/o  support  system 
c  the  SIMULA-like  simulation  system 
rl  a  chess-playing  program 


A  generally  accepted  value  for  i/p/d  is  five  for 
systems  written  in  assembly  language;  thus,  we 
see  a  productivity  increase  of  4  to  30  resulting 
from  the  use  of  Bliss.  So  far  as  we  are  able  to 
determine  the  quality  of  these  systems,  measured 
by  code  size  and  speed,  are  comparable  to  (say 
within  10%),  or  surpass  those  written  in  assembly 
language.  The  quality  of  these  systems  when 
measured  by  such  criteria  as  readability  and  mod- 
ifyability  certainly  exceeds  that  of  systems  writ¬ 
ten  in  assembly  language,  but  it  is  nearly  im¬ 
possible  to  assign  quantitative  values  to  these 
measures. 

Looking  more  closely  at  specific  features  of 
the  language  which  were  considered  “experi¬ 
mental'’  at  the  time  of  the  initial  design,  some 
have  been  a  resounding  success,  others  have 
failed  in  one  way  or  another.  For  example,  the 
removal  of  the  goto,  the  structure  mechanism, 
and  the  "match"  between  the  logical  Bliss  ma¬ 
chine  and  the  physical  computer  on  which  it  is 
implemented,  are  counted  as  substantial  suc¬ 
cesses.  One  of  our  notable  failures  was  in  not 
recognizing  the  need  for  incorporating  Bliss  into 
a  “total  system”  including  a  specialized  editor, 
debugging  support,  teaching  aids,  etc. 

One  outgrowth  of  the  experience  gained  from 
the  use  of  Bliss  merits  special  mention— the  tim¬ 
ing  package.  Systems  such  as  those  written  in 
Bliss  are  usually  large,  and  quickly  exceed  the 
implementor's  ability  to  grasp  the  interaction  be¬ 
tween  their  various  parts.  Even  though  a  lan¬ 
guage  such  as  Bliss  facilitates  the  modification 
of  a  system  to  improve  its  performance  ("tuning” 
it)  it  is  seldom  clear  what  parts  of  the  system 
need  such  attention.  Human  intuition  about  such 
things  is  usually  very  poor.  Therefore,  a  set  of 
Bliss  routines  has  been  developed  which  makes 
dynamic  measures  of  a  system's  performance 
and  displays  information  such  as  the  space  and 
time  devoted  to  various  portions  of  the  system, 
the  interaction  of  its  various  components,  etc. 
The  design  and  further  development  of  the  timing 
package  and  other  similar  support  tools  Is  cur¬ 
rently  one  of  the  major  research  activities  cen¬ 
tered  around  Bliss. 


Conclusion 


An  attempt  has  been  made  to  present  a  design 
rationale  and  its  manifestation  in  Bliss.  One  in¬ 
terpretation  of  this  rationale  is  an  indirect  defi¬ 
nition  of  the  systems  programming  problem  area. 
In  the  simplest  case  this  manifests  itself  in  a 
break  with  the  traditional  interpretation  of  identi¬ 
fiers  in  higher-level,  languages,  and  in  the  conse¬ 
quent  demand  on  the  programmer  to  be  con¬ 
sciously  aware  of  the  distinction  between  names 
and  values.  The  structure  mechanism  may  be 
interpreted  as  a  statement  of  judgment  as  to  the 
extreme  importance  of  the  representation,  modi¬ 
fication,  and  allocation  issues  in  systems  pro¬ 
gramming — and  hence  that  these  issues  must  be 
explicitly  within  the  programmer’s  attention  and 
control. 
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The  Kernel  Approach  to  Building 
Software  Systems 

Allen  Newell 
Peter  Freeman 
Donald  McCracken 
George  Robertson 

In  this  short  essay  we  will  discuss  a  possible 
approach  to  building  software  systems.  Our  in¬ 
terest  in  building  systems  is  driven  most  directly 
by  involvement  in  the  construction  of  artificial 
intelligence  systems.  But  building  large  systems 
of  programs  is  a  fundamental  activity  throughout 
all  of  computing  and  has  independent  status  as  a 
central  problem  in  computer  science.  The  formid¬ 
able  difficulties  that  have  emerged  in  producing 
third  generation  software  systems  well  illustrate 
the  problem. 

The  scheme  to  be  explored  for  creating  soft¬ 
ware  systems  is  based  on  growth  from  a  small 
kernel  of  code  and  data.  The  approach  responds 
to  somewhat  different  considerations  than  the 
more  widely  used  alternatives  of  macro-assem¬ 
blers  and  higher  level  languages.  A  full  treatment 
would  require  laying  out  the  existing  approaches, 
as  currently  understood,  and  providing  a  com¬ 
parative  analysis.  The  purpose  of  this  paper, 
however,  will  be  served  by  a  characterization  of 
what  is  involved  in  the  kernel  approach. 

We  have  been  experimenting  on  the  PDP-10 
for  some  time  with  a  succession  of  kernel  sys¬ 
tems:  L*(A),  L*(B) .  We  must  emphasize  that 

the  approach  is  highly  experimental  and  that 
substantial  issues  remain  unresolved  so  that  we 
focus  here  on  some  of  the  implications  of  using 
the  kernel  approach  to  system  building.  L*(F), 
the  version  which  has  received  the  most  polish¬ 
ing  and  use,3  will  serve  as  an  example  to  make 
our  points  concrete.  Its  specifications  are  sum¬ 
marized  briefly  in  the  Appendix. 


The  idea  of  evolving  a  system  from  a  small  be¬ 
ginning  is  not  new.  It  supplies  some  of  the  fas¬ 
cination  that  computer  science  has  always  had 
with  bootstrapping  and  recursion.  A  widespread 
variant,  for  example,  is  getting  compilers  to  com¬ 
pile  more  efficient  versions  of  themselves.  The 
concept  of  the  growing  machine,  developed  by 
Carr  and  his  students  at  Pennsylvania'  has  some 
of  the  same  spirit.  Also  Nievergelt  has  built  a 
minimal  list  processing  system  suitable  as  a  basis 
for  more  complex  list  processors.3  But  probably 
the  most  explicit  kernel  development  is  an  ex¬ 
perimental  system  called  WISP,  developed  a  few 
years  ago  by  Maurice  Wilkes,5  which  stressed 
not  only  bootstrapping,  but  also  starting  with  a 
small  initial  system.  WISP  has  had  some  prog¬ 
eny4  and  possibly  should  be  taken  as  the  spirit¬ 
ual  ancestor  of  kernel  software  systems.  But  the 
idea  is  so  fundamentally  attractive  that  undoubted¬ 
ly  other  such  systems  have  been  created,  not 
all  of  which  have  seen  the  light  of  publication. 


The  Basic  Idea  of  a  Software  Kernel 

A  kernel  software  system  is  a  small  nucleus 
(i.e.,  kernel)  of  code  and  data  that  grows  to  be¬ 
come  a  larger,  more  complex  system,  The  kernel 
provides  a  base  for  an  expanding  range  of  sys¬ 
tems,  as  shown  in  Figure  1.  The  arrows  in  the 
figure  represent  evolution  through  time.  The  kernel 
evolves  into  a  system  with  system  building  capa¬ 
bilities,  which  then  evolves  into  a  particular  ap¬ 
plication  system  (in  our  case,  an  artificial  inte1' 
gence  program).  We  draw  a  tree  to  show  h„..< 
each  use  of  the  kernel  system  to  build  a  new 
program  follows  a  different  linear  line  of  evolu¬ 
tion  that  branches  off  either  earlier  or  later  from 
its  sibling  system.  We  have  shown  each  system 
as  containing  the  whole  of  the  preceding  system 
from  which  it  grew.  However,  nothing  prevents 
a  final  application  system  from  being  totally 
separate  from  the  system  that  produces  it  (as  a 
compiled  program  is  distinct  from  its  compiler). 

We  will  finesse  the  question  of  the  exact  nature 
of  software  systems  and  of  system-building  sys¬ 
tems.  As  a  definitional  matter,  we  can  take  a 
software  system  as  a  body  of  code  and  data  that 
has  the  capabilities  of  producing  further  pro¬ 
grams;  a  system-building  system  thus  being  one 
capable  of  producing  further  systems.  By  enu¬ 
meration,  software  systems  contain  facilities  for 
creating,  executing,  debugging,  filing,  editing, 
and  managing  programs.  Accurate  characteriza¬ 
tion  of  the  nature  of  software  systems  is  ulti¬ 
mately  critical  to  the  design  of  system-building 
systems,  but  is  beyond  the  limits  of  this  essay. 

The  two  fundamental  notions  that  define  the 
design  philosophy  of  a  kernel  system  are  small 
initial  size  and  self-sufficiency  for  growth.  Out 
of  these  two  must  come  whatever  advantages 
the  approach  has.  Let  us  examine  each  in  turn. 


Small  initial  size.  Large  systems  must  eventual¬ 
ly  be  grown.  Thus  the  advantages  of  small  size 
directly  affect  only  the  initial  system.  But  small 
size  can  insure  that  the  kernel  itself  can  be  easily 
constructed  and  completely  debugged.  It  can 
insure  that  the  user  can  fully  understand  the 
kernel  and  that  radical  modification  is  possible. 

The  advantages  just  enumerated  stem  not  from 
the  size  of  the  kernel  in  absolute  terms,  but 
from  size  relative  to  the  capabilities  of  human 
programmers.  The  L*(F)  kernel  (see  Appendix) 
appears  to  be  small  enough  to  gain  the  advan- 
tages.  For  instance,  the  first  implementation, 
L  (D),  was  constructed  and  debugged  by  one 
man  in  about  five  months.  Subsequent  versions, 
such  as  L‘(F),  have  taken  on  the  order  of  half  a 
man-month,  even  though  involving  substantial 
conceptual  modifications  implicating  more  than 
50%  of  the  code.  The  L * (F)  kernel  appears  to  be 
virtually  bug  free  after  an  additional  man-month 
of  polishing. 

The  small  initial  size  of  the  kernel  is  essentially 
a  commitment  to  simplicity  as  a  design  philoso¬ 
phy.  Size  per  se  does  not  guarantee  simplicity, 
of  course.  It  can  be  thrown  away  by  introducing 
complexity  and  baroqueness  at  any  juncture. 
Thus,  a  requirement  of  simplicity  must  enter  into 
each  design  decision  in  the  development  of  the 
kernel  and  of  the  strategies  for  growth. 


In  L*(F)  the  kernel  has  the  simple  structure  of 
an  independent  set  of  subroutines,  each  typically 
5-15  instructions  long.  The  maximum  routine  is 
60  instructions,  dictated  by  the  need  to  deal 
with  the  essentially  arbitrary  i/o  interface  of  the 
PDP-10  monitor.  The  depth  of  sub-routine  nest¬ 
ing,  which  indicates  the  interdependency  in  a  set 
of  routines,  is  at  most  two  in  almost  all  cases. 
Uniform  naming  and  coding  conventions  can  be 
maintained  throughout.  Thus,  the  amount  of  in¬ 
formation  needed  to  comprehend  any  part  of  the 
kernel  is  small. 

The  advantages  given  above  of  small  size  and 
simplicity  show  up  primarily  in  terms  of  ease  of 
understanding  and  modifiability  (e.g.,  another  one 
is  ease  of  producing  complete  and  comprehensi¬ 
ble  documentation).  These  requirements  are  de¬ 
sirable  in  any  system,  but  they  are  absolutely 
central  to  the.  kernel  system  approach.  In  many 
design  philosophies,  one  strives  to  construct  an 
interface  with  the  user  (consisting  primarily  of  a 
higher  level  programming  language)  that  is  suf¬ 
ficiently  smooth  and  self-contained  that  the  user 
need  never  be  concerned  with  the  underlying 
structure  that  realizes  the  interface.  Ease  of  un¬ 
derstanding  applies  only  to  the  face  presented 
to  the  user.  With  a  kernel  system,  each  ultimate 
user  system  is  potentially  grown  from  the  kernel 
itself  (though  it  may  initially  start  off  from  some 
advanced  base).  All  aspects  of  the  kernel  must 
be  understandable  to  permit  the  user  to  grow 
the  system  in  ways  appropriate  to  his  own  needs. 


Self-sufficiency  for  growth.  We  can  contrast  a 
system  that  is  grown  by  means  of  mechanisms 
internal  to  it  with  a  system  that  is  produced  as  a 
passive  object  by  some  set  of  external  tools.  A 
compiler  is  an  example  of  an  external  system,  as 
is  a  text  editor.  A  kernel  system  is  an  example 
of  a  system  capable  of  internal  growth.  A  priori, 
neither  design  philosophy  is  better;  it  is  doubtful 
that  any  such  general  approach  can  emerge  as 
preferred  for  all  systems  building  tasks.  How¬ 
ever,  the  two  philosophies  lead  in  different 
directions. 

Growth  means  adding  instructions  and  data, 
debugging  them,  and  providing  for  their  execu¬ 
tion  and  the  use  of  their  output.  Growth  in  this 
context  must  be  extended  to  modification  and 
contraction  of  existing  structure.  Indeed,  the 
structures  provided  in  early  stages  of  growth 
are  almost  always  deficient  in  some  respects, 
e.g.,  efficiency,  and  require  reshaping  or  replace¬ 
ment  later. 

For  growth  to  be  internal  requires  that  all 
mechanisms  to  effect  ihat  growth  must  be  in 
the  kernel.  This  requirement  can  be  satisfied  in 
a  highly  indirect  way,  of  course.  The  kernel  may 
not  contain  the  tools  necessary  for  a  given  task, 
but  only  the  tools  necessary  to  construct  these 
tools.  Bootstrapping  as  a  design  philosophy  im¬ 
plies  the  emergence  of  ultimate  results  through 
an  extensive  cycle  producing  tools  for  tools  for 
tools. 

It  is  doubtful  whether  an  invariant  set  of  initial 
functions  must  be  provided  by  a  kernel.  For  one 
thing,  different  machine  environments  will  impose 
different  functional  requirements.  For  another, 
there  may  well  be  alternative  bases.  The  set  of 
functions  provided  by  the  L*(F)  kernel,  operating 
within  the  PDP-10  time-sharing  monitor,  serves 
as  an  example.  We  state  these  functions  in  gen¬ 
eral  terms,  though  they  are  realized  in  specific 
ways  for  L*(F),  as  indicated  in  parentheses: 
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(1)  Creation  of  internal  symbols  to  designate 
data  structures  (addresses), 

(2)  Creation,  manipulation  and  interpretation 
of  a  class  of  arbitrary  symbolic  expres¬ 
sions  (lists). 

(3)  Input  and  output  to  a  standard  user  in¬ 
terface  (teletype). 

(4)  Creation  and  modification  of  external 
names  to  be  in  correspondence  with  inter¬ 
nal  symbols  (name  table). 

(5)  Reading  and  writing  to  secondary  mem¬ 
ory  (disk  files  via  monitor). 

(6)  Access  to  all  of  the  entities  in  the  kernel 
(preassigned  external  names  for  all  kernel 
routines  and  data). 

(7)  Creation  and  recognition  of  arbitrary  bit 
patterns  (operations  to  go  from  lists  to 
bits  and  bits  to  lists). 

(8)  Saving  an  existing  instance  of  the  system 
and  restarting  a  copy  of  it  at  a  later  date 
(operators  to  evoke  save  and  restart 
mechanisms  in  monitor). 

(9)  Recovery  from  error  and  exploration  of 
the  errorful  instance  of  the  system  (con¬ 
text  swapping  operation  to  establish  a 
viable  operating  context). 

(10)  Locus  of  control  at  the  user  interface 
top-most  level  of  control  reads  input  from 
teletype  to  be  interpreted  as  program). 

(11)  Enough  resources  to  avoid  sudden  death 
and  access  to  additional  resources  (initial 
available  space  and  operations  to  get 
more  from  PDP-10  monitor). 

This  list  of  functions  differs  considerably  from 
that  associated  with  a  programming  language, 
such  as  Algol,  for  the  emphasis  is  on  heirvg  a 
viable  self-contained  system.  Thus,  the  ability 
to  save  and  restart  the  system  and  to  survive 
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with  operating  systems,  show  up  as  critical  initial 
functions.  The  specification  of  locus  of  control 
at  the  user  interface  (item  10)  is  to  be  especially 
emphasized.  This  is  essentially  the  direct  mode 
of  execution  existing  in  many  conversational  pro¬ 
gramming  languages  (e.g.,  see  the  description  of 
LCC  in  the  1969  Annual  Review).  With  this  con¬ 
trol  the  user  plays  the  role  of  the  executive 
routine,  executing  operations  singly  and  at  will, 
shaping  the  system  as  required. 


Many  things  are  missing  from  this  list  that  must 
ultimately  be  provided  in  any  system-building 
system  and  some  of  the  functions  in  the  list  are 
provided  only  in  rudimentary  form.  For  instance, 
access  to  the  secondary  memory  is  essential 
right  at  the  beginning,  but  a  rather  elementary 
capability  suffices.  (In  L*(F)  It  is  read  and  write 
from  a  single  fixed  file.)  Some  of  the  missing 
facilities  that  come  immediately  to  mind  are: 

(1)  Editing 

(2)  Tracing  programs 

(3)  General  communication  to  monitor 

(4)  General  storage  and  retrieval  of  files 

(5)  Assembly  of  machine  routines 

(6)  Modification  of  user  interface 

(7)  Higher  level  language  at  user  interface 

(8)  Creation  of  new  data  types  with  their 
proper  opeiations. 

(9)  Space  management 

(10)  Error  detection  with  diagnostics 

All  of  these  must  be  grown  with  the  facilities 
given  initially  in  the  kernel.  This  involves  a  boot¬ 
strapping  procedure  in  which  elementary  tools 
are  built  and  from  these  still  other  tools  are  de¬ 
veloped.  For  instance  in  the  bootstrapping  se¬ 
quence  developed  for  L*(F),  the  first  thing  that  is 
done  is  to  create  ways  of  modifying  the  interpre¬ 
tation  given  to  the  input  stream,  so  that  some 
new  notation  can  be  introduced.  Later  in  the 
sequence  the  initially  existing  limitation  on  ex¬ 
ternal  names  to  five  characters  (which  permitted 
a  simple  name  table)  is  lifted  by  replacing  the 
entire  external  naming  system.  This  new  system 
is  such  that  it  permits  the  introduction,  one  by 

one,  of  the  vgrini-9  n  »a,11  ;1  d  frltjWt  (Cv3l 

language  at  the  user  interface.  These  later  nota¬ 
tions  supersede,  of  course,  the  original  mecha- 
■f&fl.  K)t  cicfifbvfTrg  various  noraiions. 

It  might  be  thought  that  there  is  a  single  boot¬ 
strapping  sequence,  but  that  is  not  the  case. 
For  example,  early  on  an  editor  and  an  inter¬ 
preter  for  stepping  through  a  program  under 
manual  control  are  introduced,  Both  are  very 
much  a  matter  of  individual  design,  and  alterna¬ 
tive  growths  of  the  system  could  dictate  sub¬ 
stantially  variant  schemes.  Thus,  the  branching 
process  indicated  in  Figure  1  occurs  at  many 
places  along  the  line  of  development. 
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Consequences  of  the  Main  Ideas 

The  two  notions — small  initial  size  (with  the 
more  general  commitment  to  simplicity)  and  self- 
sufficiency  for  internal  growth — constitute  the 
central  design  philosophy  of  a  kernel  system. 
But  consequences  for  additional  features  of  de¬ 
sign  philosophy  flow  from  them.  Some  of  these 
need  not  be  followed,  for  in  growing  a  kernel 
into  a  larger  system  it  can  .be  shaped  ultimately 
to  quite  divergent  strategies.  But  these  addi¬ 
tional  characteristics  are  consonant  with  the 
basic  philosophy  and  serve  to  exploit  it. 

Total  accessibility.  The  point  of  growing  a 
large  system  from  a  small  beginning  is  to  permit 
all  aspects  of  the  system  to  be  shaped  by  the 
ultimate  needs.  Any  aspect  of  a  pre-existing  sys¬ 
tem  can  become  a  limiting  factor  on  the  efficiency 
or  abilities  of  a  final  user  system.  It  has  always 
been  an  important  consideration  in  system-build¬ 
ing  systems  that  they  have  complete  access  to 
the  total  facilities  of  the  target  machine.  This  at 
least  provides  the  potentiality  of  designing  user 
systems  with  maximum  efficiency  and  capability. 
The  continued  popularity  of  assemblers  is  due  in 
part  to  the  transparent  way  in  which  they  provide 
complete  access  to  the  machine's  facilities. 

Total  accessibility  is  a  combination  of  require¬ 
ments,  some  on  ease  of  understanding  of  the  sys¬ 
tem,  some  on  the  available  means  for  construct¬ 
ing  new  systems.  The  emphasis  earlier  on  small 
initial  size  and  simplicity  indicates  how  a  kernel 
system  deals  with  requirements  on  ease  of  under¬ 
standing.  We  are  concerned  here  with  the  means 
for  constructing  new  systems.  One  aspect  is 
access  to  the  kernel  itself.  In  L*(F)  this  is  pro¬ 
vided  by  having  external  names  for  all  the  rou¬ 
tines  and  data  structures  in  the  kernel  and  by 
having  all  of  the  kernel  in  the  address  space 
( i . e . ,  internal  symbols  to  designate  every  cell  in 
the  kernel). 


The  most  important  aspect  of  total  accessibil¬ 
ity  is  being  able  to  make  use  of  all  of  the  ma¬ 
chine's  basic  facilities.  One  course  is  to  mirror 
each  feature  of  the  underlying  machine  in  the 
operations  of  the  kernel  (in  the  manner  of  an 
assembler).  Give  the  complexity  of  current  ma¬ 
chines  (e.g.,  many  instruction  types  and  hundreds 
of  individual  instructions)  this  conflicts  strongly 
with  the  requirements  of  simplicity  and  small 
initial  size.  Attempting  to  accomplish  it  in  the 
initial  system  anyway  forces  an  impoverished 
and  minimal  scheme.  Assemblers  show  just  such 
impoverishment  in  comparison  with  higher  level 
language  systems.  The  solution  used  in  !_*(F)  is 
to  delay  access  to  the  total  machine  until  later 
in  the  evolution.  The  provision  in  the  kernel  of 
a  basic  bit  facility  (item  7)  yields  the  logical 
capability  to  lay  down  arbitrary  code  and  the 
provision  of  the  general  symbolic  manipulation 
system  (item  2)  yields  the  potential  for  construct¬ 
ing  linguistically  suitable  schemes  for  designating 
new  instructions,  routines  and  data  types. 
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Integrated  programming  environment.  Conver¬ 
sational  language  systems,  such  as  Joss  and 
LCC,  have  moved  toward  providing  all  computing 
functions— program  definition,  editing,  execution, 
debugging,  storage  and  retrieval  on  files,  etc.— 
with  a  common  language.  It  is  no  longer  neces¬ 
sary  in  such  systems  continually  to  change  be¬ 
tween  distinct  (and  generally  non-cooperating) 
subsystems,  each  with  their  own  conventions,  to 
perform  the  different  tasks  associated  with  build¬ 
ing  programs.  This  is  called  an  integrated  pro¬ 
gramming  environment  and  its  desirability  is 
widely  recognized. 

Integrated  environments  occur  only  rarely  out¬ 
side  of  specialized  conversational  systems.  The 
design  philosophy  inherent  in  most  operating 
systems  encourages  a  plurality  of  distinct  pro¬ 
cessors  and  languages,  e.g.,  assemblers,  editors, 
higher  languages,  the  command  language,  file 
systems,  etc.  Most  system  building  is  accom¬ 
plished  in  this  kind  of  an  environment. 

The  kernel  system  leads  naturally  to  an  em¬ 
phasis  on  attaining  an  integrated  programming 
environment.  It  is  consonant  with  the  already 
established  goal  of  simplicity.  Since  the  eventual 
system  has  roots  all  the  way  back  to  the  kernel, 
there  is  less  inclination  for  a  layered  structure 
of  system  and  subsystem  to  grow  up,  which  is 
the  genesis  of  multiple  language  systems.  If  a 
partially  grown  system  appears  to  be  congealing 
into  clusters  of  subsystems  with  distinct  con¬ 
ventions,  then  the  system  can  be  regrown  from 
an  earlier  point  and  shaped  to  a  more  homoge¬ 
neous  form. 


Modest  experience  with  L*(F)  indicates  that 
a  unified  environment  may  be  rather  easily 
achieved,  mainly  because  at  appropriate  stages 
of  growth  the  adding  of  new  facilities  with  di¬ 
verse  functions  requires  only  small  amounts  of 
new  program.  The  initial  language  of  L*(F)  is  a 
simple  list  language  called  L‘L,  which  is  written 
horizontally  and  whose  coding  density  is  not  un¬ 
like  that  of  LISP.  In  this  language  a  simple  on¬ 
line  editor  requires  a  few  lines;  a  monitor  for 
manually  stepping  through  programs  requires 
less  than  a  page  of  code;  a  system  for  entering 
text  requires  less  than  half  a  page.  All  these 
come  along  rather  early  in  the  bootstrapping 
sequence,  though  not  before  some  other  tools 
have  been  constructed.  A  rudimentary  compiler 
to  transform  L*L  expressions  into  machine  calls 
(thus  eliminating  the  interpreter)  requires  less 
than  two  pages  of  code  and  a  primitive  assembler 
without  macro  features  (unneeded  in  L*  with  its 
general  symbolic  capabilities)  requires  about  two 
pages.  Some  of  the  simplicity  of  these  systems 
arises  from  the  design  philosophy  of  creating  an 
integrated  programming  environment.  Each  aug¬ 
mentation  relies  on  the  existing  mechanisms  and 
conventions,  being  just  the  necessary  growth  to 
provide  the  additional  functions. 
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Multiple  use  of  structure.  Using  one  structure 
o  provide  the  same  function  throughout  a  system 
is  a  common  practice.  When  systems  a^ built 

eSstnioan!;emel*hthe  PossibilitV  of  multiple  use 
exists  along  another  direction.  The  structures 

sysemcanV  ,U"C,5n  in  ,he  ^"'building 

ystem  can  also  provide  that  function  in  the  ulti- 
■  aPPl'cation  system.  For  example,  the  syntax 
naiyzer  used  in  the  system-building  systern  can 

sts^m0 fit  ij^  SVntaX  analyzer  in  ^user 

system.  (It  is  a  rare  compiler  that  can  transfer 

use°there7aX  a"a'yZer  ‘°  30  °bject  pro9ram  f°r 

Severn!  effects  follow  from  this  multiple  use 
of  structure.  It  contributes  to  the  maintenance  of 
simplicity  and  it  undoubtedly  provides  some  sav¬ 
ings  m  space.  But  the  main  effect  is  the  use  of 

-anrthe  creTtioeno?ad  ^  debu"ed  comP°"a"'s 

'  lMe  station  of  a  new  system 

frnme.hability  t0  US®  s,ruct“res  in  this  way  arises 
from  the  commitment  of  internal  nroi«/»h  >.•  u 

thoroughly  b,„rs  ,he  llne  hSoh^l-S 

are  bSll'^Th  app.llcallon  STSI™  Now  systems 
"nished  Wem-building 
h-.  tr-  '9rown’  say>  by  someone  else)  but  hv 
backing  up  and  starting  off  again  in  a  new  direc¬ 
tion  from  an  earlier  point. 

haS  30  addi,i°nal  design  feature  that 
serves  to  enhance  the  extension  of  existina  stmr 
ures  ,o  new  contexts.  The  dale 

a  dismeTe  sToMS  W,,icl’„desi3™">  'hem)  lore, 
a  mscrete  set  of  types.  Differential  action  de- 

both  fast  and  ***  ■ °f  data  being  Processed  is 

omarization  f  en,6nt'  For  exampfe,  a  natural 
i  rganization  for  a  print  routine  is  as  a  set  of 
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The  kernel  conlalns  only  a  small  set  ol  Inilial 
ypes,  but  new  types  can  be  added  at  will  |n 
fact  one  Gf  the  main  techniques  for  growth  is  the 
addition  of  types.  Extension  encourages  ,tt  no 
new  subsystems  into  the  existing  framework  o? 
ypes,  thereby  extending  existing  facilities  An 
I  ustration  would  be  the  creation  of  a  type  LIS^ 

which  Th  Z  eXiS,inS  interpretive  T.mciure 

hies  ,no9hod',in9-adebU99in9'  a"d  L* 

mes  to  be  immediately  used  in  a  LISP  context.  j 


Personalization.  The  notion  of  a  system-build 

inysteSmsteamdaenntCdU;a9eS  producin9  a  multitude  of 
systems  adafjted  to  special  circumstances  The 

notion  of  the  kernel  system  enhances  this  {0  the 
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he  rule.  Personalization  is  not  simply  The  instT 

tutionalization  of  the  natural  tendencies  of  svs- 

ems  programmers  to  be  idiosyncratic  Rather 

it  means  hat  a  system  should  be  built  as  much 

potePn0«“iblrsSerVe  ^  individuali-d  needs  of 
Rigid  standardization  of  programming  systems 
°  T*  9h  'eVel  °f  deva'opment  (as  Tn 
mon  r  *haS  S°me  important  advantages.  Com- 

mh  rnm  mS0Ver  lar9e  poPulat'ons  of  users  per¬ 
mit  communication  of  programs  and  ideas  and 

temTSn  ^  need  °f  con,inual,y  'earning  new  sys- 
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the  course  of  computer  science  research,  these 
dvantages  are  often  outweighed  by  the  need  to 
s  ape  the  system  to  new  demands  a'nd  concepts 
Simi^rly,  extracting  the  utmost  efficient  from 
a  machine,  which  implies  the  complete  adaDta 
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emphasized  in  discussing  accessibility  Since  it 
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Design  iteration.  Iteration  of  a  design  is  gen¬ 
erally  considered  a  laudable  goal.  In  large  soft¬ 
ware  systems  (as  in  some  other  areas)  it  rarely 
happens,  primarily  because  of  the  extensive  effort 
involved  and  the  inevitable  occurrence  of  un¬ 
anticipated  difficulties  that  stretch  out  the  con¬ 
struction  effort  beyond  all  preset  deadlines.  Typi¬ 
cally,  design  iteration  occurs  at  the  specification 
stage,  then  the  design  is  committed  and  an  initial 
version  is  brought  into  being.  Once  in  use,  modi¬ 
fications  and  revisions  are  made  (in  successive 
“releases”  of  the  system)  attempting  to  adapt 
the  system  to  the  actual  environment. 

The  kernel  system  approach  appears  to  lead 
to  a  highly  iterative  design  style.  Systems  are 
grown  and  regrown  from  early  points  in  the 
tree  of  development  (Figure  1),  and  design  be¬ 
comes  an  experimental  activity  rather  than  an 
analytic  one.  Part  of  the  reason  for  this  design 
style  is  certainly  the  small  initial  size,  which  cf 
course  must  eventually  give  way  to  mature  sys¬ 
tems  of  large  size.  But  part  of  the  reason  also 
appears  to  be  that  the  growing  system  contains 
substantial  investment  in  structures  that  help  to 
grow  the  system  further.  Thus  easy  regeneration 
of  the  system  from  early  stages  becomes  an  im¬ 
portant  subgoal  in  the  design  of  a  system.  Summary.  All  of  these  aspects  of  system  de- 

Our  experience  in  L‘(F)  on  iterative  design  of  sign  just  discussed  are  consonant  with  the  idea 

large  application  systems  through  regeneration  of  a  kernel  system  building  system.  However, 

is  still  minimal.  We  do  have  experience  about  they  are  not  essential.  It  is  quite  possible  that 

iteration  of  design  for  the  kernel  itself.  So  far  highly  successful  lines  of  development  would 

during  the  year  in  which  we  have  devoted  sub-  shun  some  of  them  entirely.  One  could  start  with 

stantial  effort  to  L‘  we  have  brought  six  systems  a  kernel,  construct  a  particular  application  sys- 

into  full  existence:  L‘(D)  through  L*(G)  on  the  tern  with  its  own  programming  language,  file 

PDP-10  and  L*  1 1  (A)  and  L *  1 1  (B)  on  the  PDP-11.  system,  etc.,  discarding  all  the  system-building 

Each  of  these  has  explored  basic  variations  in  scaffolding  so  that  no  trace  of  it  remained  in  the 

the  design  space  of  kernel  systems.  Several  final  application  system.  But  these  notions  of 

more  iterations  seem  indicated  at  present  before  personalization,  design  iteration,  multiple  use  of 

we  will  finally  know  enough  about  the  kernel  to  structures,  etc.,  appear  to  be  the  ideas  to  be 

create  a  final  system,  all  of  whose  further  modi-  exploited  to  make  the  kernel  approach  to  system 

fications  should  arise  through  internal  growth.  building  viable. 
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The  Essential  Problems 

So  far  we  have  defined  the  essential  nature  of 
the  kernel  system  approach  to  system  building 
and  explored  the  various  directions  in  which  its 
advantages  might  lie.  But  there  are  some  diffi¬ 
culties,  too.  A  kernel  system  depends  on  getting 
most  of  the  ultimate  facilities  for  system  building 
indirectly,  providing  only  the  tools  for  their  con¬ 
struction  (and  sometimes  being  even  more  re¬ 
mote).  Looking  at  current  schemes  for  building 
systems,  four  main  things  have  been  provided  by 
one  or  another  system:  (1)  direct  and  transparent 
access  to  the  underlying  machine;  (2)  higher 
level  languages;  (3)  efficient  code  production  and 
(4)  supporting  facilities,  predefined  and  working, 
evocable  through  a  command  language.  None 
of  these  is  available  directly  in  the  kernel'  all 
have  to  be  built. 

The  essential  tension  (to  use  a  favorite  phrase 
of  Bill  Wulf's)  is  between  the  effort  to  be  spent 
in  building  up  these  facilities  and  the  advantages 
of  the  user  having  shaped  them  himself  to  his 
own  needs.  On  the  effort  side  must  be  counted 
not  only  the  programming  and  debugging  re¬ 
quired,  but  also  the  intellectual  investment  by  the 
user  In  understanding  the  functions  to  be  built 
and  the  mechanism  that  will  realize  them.  It  may 
turn  out  that  users  simply  will  not  wish  to  under¬ 
stand  all  the  subsystems  involved  in  their  appli¬ 
cation  system.  More  likely,  the  use  of  kernel  sys¬ 
tems  will  be  restricted  to  professional  systems 
programmers  and  will  not  be  a  tool  for  the  casual 
user.  Our  own  intended  use,  to  build  artificial 
intelligence  systems,  certainly  is  of  this  sort. 


Success  of  the  kernel  system  approach  de¬ 
mands  that  all  of  the  ultimate  facilities  of  a  sys¬ 
tem-building  system  (editors,  translators,  higher 
level  languages,  etc.)  be  obtainable  without  un¬ 
due  pain  and  effort.  Otherwise  it  is  surely  not 
worth  anyone's  while  to  work  through  their  con¬ 
struction.  Given  that  kernels  start  with  so  little 
and  given  the  general  experience  with  how  much 
work  it  is  to  build  systems  programs,  this  appears 
highly  implausible  on  the  face  of  it.  The  distance 
between  the  initial  point  and  a  fully  developed 
system  simply  appears  to  be  too  great.  We  did 

note  some  positive  evidence  earlier  from  L*(F) _ 

that  subsystems  require  very  little  code.  But  the 
evidence  is  far  from  conclusive  yet.  That  the 
distance  really  can  be  covered  with  ease  is  un¬ 
doubtedly  the  most  important  hypothesis  under¬ 
lying  the  use  of  kernels  for  system-building. 
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Appendix: 

Description  of  L*(F)  Kernel 

L*(F)  is  a  kernel  system  operational  on  the 
PDP-10.2  Table  1  lists  some  of  its  main  charac¬ 
teristics.  Space  prohibits  discussing  these  in 
detail,  but  we  can  comment  on  a  few  of  them 
that  relate  to  the  central  design  idea. 

First  is  the  adoption  of  a  simple  list  language 
(called  L*L)  as  the  initial  language.  As  is  well 
known,  only  a  few  primitive  actions  suffice  for  an 
essentially  complete  list  facility  for  doing  sym¬ 
bolic  manipulation. 

A  second  important  feature  is  the  use  of  a 
homogeneous  symbol  system.  Symbols  are  taken 
to  be  addresses  and  are  used  to  refer  to  every¬ 
thing.  For  instance,  there  is  a  symbol  (an  ad¬ 
dress)  corresponding  to  each  of  the  128  charac¬ 
ters. 

A  third  major  mechanism  is  a  universal  type 
system.  Every  symbol  has  a  type,  which  de¬ 
scribes  the  nature  of  the  data  structure  it  desig¬ 
nates.  Initially,  only  a  minimum  number  of  types 
are  provided:  list  (the  basic  data  structure),  pro¬ 
gram  list  (list  to  be  interpreted  as  programs), 
Integer  (required  for  incrementing  and  differenc¬ 
ing  addresses),  machine  (to  identify  machine 
code),  character  (the  fixed  set  of  128  symbols), 
and  cells  (everything  else).  Everything  has  a  type, 
even  the  registers  of  the  machine  (type  list  and 
type  cell),  the  size  of  the  symbol  table  (type 
integer)  and  each  instruction  in  the  kernel  (type 
machine).  Types  are  totally  dynamic:  the  type  of 
any  symbol  can  be  changed,  new  types  can  be 
created,  the  functions  associated  with  a  type  can 
be  changed,  the  total  number  of  types  in  the 
system  can  be  increased  (or  decreased). 


Action  can  be  type  dependent  everywhere,  so 
there  is  always  available  a  relevant  discrimina¬ 
tion  that  can  be  used  to  direct  processing.  Thus, 
print  routines  operate  conditionally  on  the  type 
of  the  symbol  to  be  printed.  To  obtain  the  ad¬ 
vantages  of  a  type  system  one  needs  to  have 
type  dependent  action  as  fast  as  possible  (for  it 
is  like  an  inner  loop  calculation)  and  for  the 
structure  that  holds  types  to  impose  no  constraint 
of  trie  types  of  data  structures.  In  L*(F)  we  pay 
a  very  high  price  for  this:  for  each  cell  of  the 
system  an  extra  cell  is  taken  to  hold  the  type 
index.  Although  the  space  cost  is  substantial 
(being  reminiscent  of  the  space-cost  paid  for  list 
structures),  the  gains  appear  to  be  impressive. 

One  feature  of  L*L  is  worth  mentioning:  the 
principle  of  semantic  interpretation.  That  is,  to 
interpret  a  symbol  in  a  program  list  the  interpreter 
associated  with  the  type  of  that  symbol  is  exe¬ 
cuted.  This  means  that  a  program  list  itself  has 
no  syntactic  structure.  For  example,  if  LIST  and 
SYMB  are  respectively  a  list  and  symbol  of  type 
list  and  TEST  is  a  program,  then  the  program  list 
(LIST  SYMB  TEST) 

results  in  TEST  being  interpreted  as  a  program 
with  LIST  and  SYMB  as  operands.  This  happens 
because  each  of  the  three  symbols  is  interpreted 
in  order,  but  the  interpreter  associated  with  LIST 
and  SYMB,  being  interpreter  for  type  list,  treats 
these  symbols  as  operands,  whereas  the  inter¬ 
preter  for  TEST  treats  it  as  a  program.  If  TEST 
were  type  machine,  then  it  would  be  executed 
as  a  machine  routine. 

The  kernel  of  L*(F)  does  not  contain  direct 
access  to  all  the  features  of  the  PDP-10  machine. 
Thus,  ultimate  access  is  obtained  by  providing 
tools  in  the  kernel.  These  are  two  special  inter¬ 
preters,  one  of  which  deposits  a  set  of  bits  in  a 
field  in  a  word,  the  other  of  which  extracts  a  set 
of  bits  from  a  word.  These  interpreters  can  be 
associated  with  various  types  of  symbols.  Initially, 
type  character  is  the  only  type  for  which  these 
instructions  make  sense,  permitting  the  packing 
and  unpacking  of  character  strings  simply  by  in¬ 
terpreting  lists  of  characters. 
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TABLE  1:  CHARACTERISTICS  OF  L*<F) 

Size  of  kernel: 

1078  instructions,  924  data  words,  7139  with  all 
available  space. 

Symbol  system: 

Homogeneous  system  of  symbols; 

Symbols  are  addresses; 

All  addresses  in  main  segment  are  symbols. 

Type  system: 

All  symbols  have  types; 

Types  form  a  small  discrete  unstructured  set  (initi¬ 
ally  16); 

Type  dependent  action  is  immediate; 

The  type  of  a  symbol  is  completely  dynamic; 

The  function  of  a  particular  type  is  dynamic  (slowly); 
Mechanized  by  putting  type  index  for  each  symbol 
(address)  In  a  corresponding  word  in  a  special 
segment  (trades  space  for  time). 

Initial  types: 

Lists,  program  lists,  machine,  Integers,  characters, 
cells. 

Initial  language: 

L*L  (a  simple  list  language  of  type  program  list); 
interpretive  (base  rate  =  30,000  .  ycies  per  second); 
Interpretation  by  executing  interpreters  associated 
with  each  type: 

For  program  lists:  interpret  each  symbol  of  list  in 
turn; 

For  machine:  Execute  machine  routine; 

For  others  (data):  Push  symbol  into  data  stack; 
Operand  and  result  communication  via  data  stack; 
Operator/operand  distinction  made  by  type  of  sym¬ 
bol  (i.e.,  by  inte-  rrt  ’"r  used  for  type); 

Control  structure: 

Loops  handled  by  repeated  interpretation  of  pro¬ 
gram  lists; 

Action  can  be  conditional  on  top  of  data  stack; 

No  direct  transfers  (no  "goto's”); 

Effective  style  of  language  is  Polish  post-fix. 

Symbol  table: 

Entries  In  Initial  table  limited  to  arbitrary  5  character 
names; 

Uses  sequential  search  for  lookup; 

Number  of  names  expandable  dynamically; 

Size  of  names  not  easily  expandable; 

Table  scheme  is  replaceable. 


Accessibility: 

All  relevant  names  in  kernel  entered  into  L*  symboi 
table; 

All  routines  In  kernel  executable  from  within  L*L; 

All  internal  structure  of  L*L  of  type  list  (data  and 
routine  stacks); 

Kernel  has  simple  structure: 

85  almost  independent  routines  (maximum  nest¬ 
ing,  2  in  almost  all  cases); 

Standard  scheme  for  communication  between  ma¬ 
chine  routines  and  environment  (including  L*L 
stacks); 

Format  lists  to  deposit  and  extract  bits  within  words. 

Interfaces  to  environment: 

Interfaces  exist  to  teletype  and  disk  (via  Monitor 
conventions); 

Communication  via  list  of  characters  (I.e.,  symbols 
of  type  character); 

Processes  by  using  special  interpreter  for  type  char¬ 
acter  (executes  L*L  process  associated  with  each 
character). 

Style  of  use: 

Conversational  (via  PDP-10  Monitor). 

Debugging  and  recovery: 

Swap  mechanism  to  reinstate  functioning  context 
and  make  buggy  context  available  for  Investiga¬ 
tion  and  correction  dynamically. 

Space  management: 

Automatic  for  lists  and  single  cells; 

No  recovery  when  exhausted  (but  creatable); 

Access  to  PDP-10  Monitor  for  more  space. 

Coding  of  kernel: 

In  Macro-10,  the  PDP-10  macroassembler. 
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tion  to  Sorting” 

Professor  P.  M.  Spira,  University  of  California 
at  Berkeley 

OSL-TOOTH,  An  Operating  System  Language” 

Mr.  Peter  Alsberg,  University  of  Illinois 
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January  1971 

"The  Structures  of  a  List  Processing  Computer" 
Dr.  Alan  Kay,  Stanford  University 

"Future  Uses  of  Minicomputers" 

Dr.  Alan  Kay,  Stanford  University 

“Implementation  of  ‘PMS’ " 

Michael  Knudsen,  Carnegie-Mellon  University 

February  1971 

"PPL — An  Extensible  Language" 

Dr.  T.  Standish,  Harvard  University 

"A  Natural  Language  Understanding  System" 

Dr.  T.  Winograd,  Project  MAC,  MIT 

"Survey  of  Graph  Representations  of  Factual 
Information 

Stu  Card,  Carnegie-Mellon  University 

"Graph  Representation  of  Floor  Plan  Layouts" 

Dr.  J.  Grason,  Carnegie-Mellon  University 

Software  implementation  and  hardware  areas 
Professor  Dr.  ir.  Van  Der  Poel,  Delft  University 

"Directed  Graph  Representation  of  Concepts  and 
Experience" 

Bill  Mann,  Carnegie-Mellon  University 

"Application  to  Electrical  Networks" 

Professor  R.  Duffin,  Carnegie-Mellon  University 

"A  Model  for  Functional  Reasoning  in  Design” 

Dr.  P.  Freeman,  Carnegie-Mellon  University 

March  1971 

Graph  Formulation  of  the  Transportation  Prob¬ 
lem” 

Professor  G.  Thompson,  Carnegie-Mellon  Uni¬ 
versity 

"DISCRETE-TIME  Machines  in  Closed  Categor¬ 
ies” 

Professor  J.  Goguen,  University  of  Chicago 


April  1971 

"Toward  a  More  General  Theory  of  Data  Struc¬ 
tures" 

Dr.  D.  Rine,  West  Virginia  University 

"The  role  of  analytic  models  and  simulation  in 
the  study  of  the  feasibility  of  a  circumferential 
communications  network” 

Peter  Cook,  IBM  Watson  Research  Center 

"The  Irrelevance  of  Resolution" 

Professor  Seymour  Papert,  MIT 

A  Set  Theoretic  Language  for  the  Description 
of  Algorithms” 

Professor  J.  Schwartz,  New  York  University 

"Computers  for  Individualized  Instruction" 

Dr.  R.  Ferguson  and  Dr.  K.  Block,  Learning  Re¬ 
search  and  Development  Center 

Flowchartable  Recursive  Specifications” 

H.  R.  Strong,  IBM 

"Program  Control  Flow  and  Data  Flow  Analysis" 
Fran  Allen,  IBM 

"Planner” 

Dr.  Carl  Hewitt,  MIT 

"Information  Processing  in  Visual  Perception” 

H.  A.  Simon,  Carnegie-Mellon  University 

"Rational  Reconditioning  of  Polynomials” 

Dr.  M.  Rabin,  Hebrew  University  and  IBM  Re¬ 
search 

"The  Technology  Chess  Program” 

J.  Gillogly,  Carnegie-Mellon  University 
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Ph.O.  Dissertations 

The  following  persons  have  been  awarded  Ph.D.'s 
in  Computer  Science  since  the  establishment 
of  the  Computer  Science  Department  in  1965. 
immediately  following  each  recipient's  name  is 
his  position  as  of  the  1970-71  school  year. 

Support  for  this  work  came  largely  from  the  Ad¬ 
vanced  Research  Projects  Agency  under  contract 
F-44620-70-C-01 07 .  The  accession  numbers  fol¬ 
low  in  parentheses  after  those  dissertations 
which  are  registered  as  reports  with  the  Defense 
Documentation  Center. 

Balzer,  Robert  M.  (Systems  and  Communication 
Sciences),  Computer  Sciences  Department, 
The  RAND  Corp.,  “Studies  Concerning  Minimal 
Time  Solutions  to  the  Firing  Squad  Synchroni¬ 
zation  Problem,"  1966,  Professor  A.  Newell 
(AD  635056). 

Berglass,  Gilbert  R.  (Systems  and  Communica¬ 
tion  Sciences),  Assistant  Professor  of  Comput¬ 
er  Science,  state  University  of  New  York  at 
Buffalo,  "A  Generalization  of  Macro  Proces¬ 
sing,"  1970,  Professor  A.  J.  Perlis. 

Caviness,  B.  F.  (Mathematics),  Associate  Profes¬ 
sor  of  Computer  Science,  University  of  Wis¬ 
consin,  “On  Canonical  Forms  and  Simplifica¬ 
tion,"  1967,  Professor  A.  J.  Perlis.  (AD  671938). 

Coles,  L.  Stephen.  (Systems  and  Communication 
Sciences),  Research  Mathematician,  Stanford 
Research  Institute,  "Syntax  Directed  Interpre¬ 
tation  of  Natural  Language,”  1967,  Professor 
H.  A.  Sirnon.  (AD  655923). 

Darringer,  John  A.  (Systems  and  Communication 
Sciences),  Consultant,  Logic  Systems  Design 
Department,  N.  V.  Philips-Electrologica.  Apel- 
doorn,  The  Netherlands,  “The  Description,  Sim¬ 
ulation  and  Implementation  of  Digital  Computer 
Processes,"  1969,  Professor  D.  L.  Parnas  and 
Professor  C.  G.  Bell.  (AD  700144). 


Earley,  Jay.  (Computer  Science),  Acting  Assistant 
Professor,  Department  of  Computer  Science, 
University  of  California,  Berkeley,  “An  efficient 
Context-Free  Parsing  Algorithm,”  1968,  Profes¬ 
sor  R.  W.  Floyd. 

Ernst,  George.  (Systems  and  Communication  Sci¬ 
ences),  Associate  Professor,  Department  of 
Computer  Science,  Computer  Engineering  Divi¬ 
sion,  Case  Western  Reserve  University,  “Gen¬ 
erality  and  GPS,”  1966,  Professor  A.  Newell. 
(AD  809354). 

Evans,  Arthur.  (Mathematics),  Lincoln  Laborato¬ 
ries,  Lexington,  Mass.,  “Syntax  Analysis  by  a 
Production  Language,"  1965,  Professor  A.  J. 
Perlis.  (AD  625465). 

Feldman,  Jerome  A.  (Mathematics),  Associate 
Professor  of  Computer  Science,  Department  of 
Computer  Science,  Stanford  University,  “A 
Formal  Semantics  for  Computer  Oriented  Lan¬ 
guages,"  1964,  Professor  A.  J.  Perlis.  (AD 
462935). 

Fikes,  Richard  E.  (Computer  Science),  Research 
Mathematician,  Stanford  Research  Institute,  "A 
Heuristic  Program  for  Solving  Problems  Stated 
as  Nondeterministic  Procedures,”  1969,  Profes¬ 
sor  A.  Newell.  (AD  688604). 

Fisher,  David.  (Computer  Science),  Burroughs 
Corp.,  Paoli  (Philadelphia),  "Control  Structures 
for  Programming  Languages,"  1970,  Professor 
A.  J,  Perlis.  (AD  708511). 
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Freeman,  Peter  A.  (Computer  Science),  Assistant 
Professor  of  Computer  Science,  Department  of 
Information  and  Computer  Science,  University 
of  California  at  Irvine,  “Sourcebook  for  OSD — 
An  Operating  System  Designer,”  1970,  Profes¬ 
sor  A.  Newell. 

Grason,  John.  (Systems  find  Communication  Sci¬ 
ences),  Assistant  Professor  of  Electrical  Engi¬ 
neering,  Department  of  Electrical  Engineering, 
Carnegie-Mellon  University,  "Methods  for  the 
Computer-Implemented  Solution  of  a  Class  of 
‘Floor  Plan'  Design  Problems,"  1970,  Professor 
H.  A.  Simon.  (AD  717756). 

Haney,  Frederick  M.  (Computer  Science),  Man¬ 
ager  of  Design,  Scientific  Data  Systems,  El 
Cegundo,  Cal.,  "Using  a  Computer  to  Design 
Computer  Instruction  Sets,"  1968,  Professor 
C.  G.  Bell.  (AD  671939). 

Iturriaga,  Renato.  (Computer  Science),  Director 
of  the  Computation  Center,  University  of  Mexi¬ 
co,  Mexico  City,  "Contributions  to  Mechanical 
Mathematics,"  1967,  Professor  A.  J.  Perlis. 
(AD  660127). 

King,  James  C.  (Computer  Science),  Research 
Staff,  T.  J.  Watson  Research  Center,  IBM  Corp., 
"A  Program  Verifier,”  1970,  Professor  R.  W. 
Floyd.  (AD  699248). 

Lindstrom,  Gary.  (Computer  Science),  Assistant 
Professor  of  Computer  Science,  University  of 
Pittsburgh,  "Variability  in  Language  Proces¬ 
sors,"  1970,  Professor  A.  J.  Perlis.  (AD  714695). 


London,  Ralph  L.  (Mathematics),  Associate  Pro¬ 
fessor  of  Computer  Science,  University  of  Wis¬ 
consin,  “A  Computer  Program  for  Discovering 
and  Proving  Sequencial  Recognition  Rules  for 
Well-Formed  Formulas  Defined  by  a  Backus 
Normal  Form  Grammar,"  1964,  Professor  A. 
Newell.  (AD  804036). 

Manna,  Zohar.  (Computer  Science),  Visiting  Re¬ 
searcher,  Computer  Science  Department,  Stan¬ 
ford  University,  "Termination  of  Algorithms," 
1968,  Professor  R.  W.  Floyd.  (AD  670558). 

McCreight,  Edward  M.  (Computer  Science),  Xerox 
Corp.,  "Classes  of  Computable  Functions  De¬ 
fined  by  Bounds  on  Computation,"  1970,  Pro¬ 
fessor  A.  R.  Meyer.  (AD  693327). 

Michell,  James.  (Computer  Science),  Xerox 
Corp.,  "The  Design  and  Construction  of  Flexi¬ 
ble  and  Efficient  Interactive  Programming  Sys¬ 
tems,"  1970,  Professor  A.  J.  Perlis.  (AD  712721). 

Moore,  James.  (Systems  and  Communication  Sci¬ 
ences),  Research  Associate,  Carnegie-Mellon 
University,  "The  Design  and  Evaluation  of  a 
Knowledge  Net  for  MERLIN,"  1971,  Professor 
A.  Newell. 

Mullin,  James  K.  (Systems  and  Communication 
Sciences),  Scientist,  Division  of  Research  In 
Epidemology  and  Communication  Sciences, 
World  Health  Organization,  Geneva,  Switzer¬ 
land,  "A  Computer  Optimized  Question  Asker 
for  Aiding  Bacteriological  Species  Identifica¬ 
tion  COQAB,"  1967,  Professor  B.  Green. 

Parnas,  David  L.  (Systems  and  Communication 
Sciences),  Associate  Professor  of  Computer 
Science,  Computer  Science  Department,  Car¬ 
negie-Mellon  University,  "System  Function  De¬ 
scription  ALGOL — A  Language  for  the  Descrip¬ 
tion  of  the  Functions  of  Finite  State  Systems, 
the  Simulation  of  Finite  Systems,  and  the  Auto¬ 
matic  Production  of  the  State  Tables  of  Such 
Systems,"  1965.  (AD  467633). 
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Pfefferkorn,  Charles.  (Computer  Science),  Assis¬ 
tant  Professor  of  Computer  Sciencr,  Purdue 
University,  "Computer  Design  of  Equipment 
Layouts  Using  the  Design  Problem  Solver 
(DPS),"  1971,  Professor  H.  A.  Simon. 

Quatse,  Jesse  T.  (Electrical  Engineering  and  Sys¬ 
tems  and  Communication  Sciences),  Vice  Pres¬ 
ident,  Berkeley  Computer  Corp.,  “A  Highly- 
Modular  Organization  of  General  Purpose  Com¬ 
puters,”  1969,  Professor  A.  Newell  and  Profes¬ 
sor  C.  G.  Bell. 

Quillian,  M.  Ross.  (Psychology),  Bolt,  Beranek 
and  Newman,  Inc.,  “Semantic  Memory,"  1967, 
Professor  H.  A.  Simon. 

Shoup,  Richard.  (Computer  Science),  Xerox  Re¬ 
search  Center,  Palo  Alto,  Cal.,  “Programmable 
Cellular  Logic  Arrays,”  1970,  Professor  C.  G. 
Bell.  (AD706891). 

Slklossy,  Laurent.  (Computer  Science),  Computer 
Science  Department,  University  of  Texas  at 
Austin,  "Natural  Language  Learning  by  Com¬ 
puter,"  1968,  Professor  H.  A.  Simon.  (AD 
671937). 

Standish,  Thomas  A.  (Computer  Science),  Assis¬ 
tant  Professor  of  Computer  Science,  Harvard 
University,  "A  Data  Definition  Facility  for  Pro¬ 
gramming  Languages,”  1967,  Professor  A.  J. 
Perlis.  (AD  658042). 


Strauss,  Jon  C.  (Systems  and  Communication 
Sciences),  Director  of  Computing,  Washington 
University,  St.  Louis,  "Identification  of  Contin¬ 
uous  Dynamic  Systems  by  Parameter  Optimiza¬ 
tion,”  1965,  Professor  A.  Lavi.  (AD  660887). 

Strecker,  William  D.  (Electrical  Engineering),  Sci¬ 
entific  Staff  Engineer,  RCA,  "An  Analysis  of  the 
Instruction  Execution  Rate  in  Certain  Computer 
Structures,”  1970,  Professor  C.  G.  Bell.  (AD 
711408). 

Wagner,  Robert  A.  (Computer  Science),  Assis¬ 
tant  Professor  of  Computer  Science,  Cornell 
University,  "Some  Techniques  for  Algorithm 
Optimization  with  Application  to  Matrix  Arith¬ 
metic  Expressions,”  1969,  Professor  A.  J.  Per¬ 
lis.  (AD  678629). 

Waldinger,  Richard  J.  (Computer  Science),  Re¬ 
search  Mathematician,  Information  Science 
Laboratory,  Stanford  Research  Institute,  "Con¬ 
structing  Programs  Automatically  Using  Theo- 
orem  Proving,”  1969,  Professor  H.  A.  Simon. 
(AD  697041). 

Williams,  Donald  S.  (Systems  and  Communica¬ 
tion  Sciences),  Principal  Member,  Technical 
Staff,  RCA  Corp.,  "Computer  Program  Organi¬ 
zation  Induced  by  Problem  Example,”  1969, 
Professor  H.  A.  Simon.  (AD  688242). 

Winikoff,  Arnold  W.  (Systems  and  Communica¬ 
tion  Sciences),  Director  of  Programming,  Blo- 
med  Computer  Services,  St.  Paul,  Minn.,  “Eye 
Movement  as  an  Aid  to  Protocol  Analysis  of 
Problem  Solving  Behavior,”  1967,  Professor  A. 
Newell. 


